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EXECUTIVE  SUMMARY 

Covert  cross-border  tunnels  are  a  security  vulnerability  that  enables  people  and  contra¬ 
band  to  illegally  enter  the  United  States.  All  of  these  tunnels  have  been  utilized  for  the  pur¬ 
pose  of  drug-  and  human-smuggling,  but  they  may  also  be  used  to  support  terrorist  attacks 
against  the  United  States.  Past  robotic  tunnel  exploration  efforts  have  had  limited  success  in 
aiding  law  enforcement  to  explore  and  map  suspect  cross-border  tunnels.  These  efforts  have 
used  adapted  explosive  ordnance  disposal  (EOD)  or  pipe-inspection  robotic  systems  that  are 
not  ideally  suited  to  the  cross-border  tunnel  environment. 

This  Counter  Tunnel  project  developed  a  prototype  robotic  system  for  counter-tunnel 
operations  to  provide  law  enforcement  agencies  and  the  warfighter  with  a  capability  for  as¬ 
sessing  tunnel-like  environments  without  sending  in  personnel  into  the  confined  space.  The 
effort  focused  on  technology  solutions  for  localizing,  exploring,  mapping,  and  characteriz¬ 
ing  tunnels,  identifying  items  of  interest,  and  locating  the  point(s)  of  entry.  It  was  sponsored 
by  the  Office  of  the  Under  Secretary  of  Defense  (OUSD)  Joint  Ground  Robotics  Enterprise 
(JGRE)  and  jointly  executed  by  Air  Force  Research  Laboratory  Airbase  Technologies  Divi¬ 
sion  (AFRL/RXQ)  Tyndall  and  SPAWAR  Systems  Center  (SSC)  Pacific.  The  Counter  Tunnel 
project  was  a  complementary  development  effort  to  the  Rapid  Reaction  Tunnel  Detection 
(R2TD)  Joint  Capability  Technology  Demonstration  (JCTD),  managed  by  U.S.  Northern  Com¬ 
mand  (USNORTHCOM). 

The  prototype  counter-tunnel  system  developed  under  this  effort  is  composed  of  a  robotic 
mobility  platform,  perception  sensor  payload,  onboard  autonomy  capability,  command  and 
control  operator  unit,  and  deployment  apparatus.  The  overall  design  was  driven  by  the  re¬ 
quirement  to  deploy  the  system  into  a  tunnel  through  a  20-centimeter-diameter  borehole. 
This  requirement  posed  many  design  and  packaging  challenges  for  the  perception  payload 
and  mobility  platform  in  order  to  fit  through  the  narrow  borehole  opening  and  still  be  able  to 
perform  the  mission  in  a  GPS-denied  environment. 

The  Counter  Tunnel  project  presented  a  unique  prototype  UGV  mobility  platform  capable 
of  insertion  and  retrieval  through  the  20-centimeter-diameter  borehole,  climbing  30-centimeter 
vertical  steps,  and  crossing  30-centimeter  gaps.  This  project  also  demonstrated  a  perception 
system  capable  of  performing  obstacle  detection,  3D  mapping,  and  GPS-denied  localization 
with  an  error  of  0.1%  after  traveling  autonomously  for  900  meters  through  a  tunnel-like  envi¬ 
ronment.  This  project  has  increased  the  technology  readiness  level  of  various  components 
of  the  counter-tunnel  systems  (platforms,  sensors,  communications,  and  payloads)  and  has 
advanced  the  work  in  GPS-denied  navigation,  3D  perception,  and  mapping.  The  prototype 
evaluations  and  expertise  gained  from  this  work  will  be  key  to  providing  robust  and  deployable 
systems  to  explore  tunnels,  caves,  mines,  and  similar  environments. 
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1.  INTRODUCTION 


1.1  PURPOSE 

The  purpose  of  the  Counter  Tunnel  project  is  to  develop  a  prototype  robotic  system  that  provides  the 
warfighter  and  law  enforcement  with  a  safe  and  effective  solution  for  exploration,  localization,  mapping, 
and  characterization  of  a  tunnel-like  environment,  identifying  items  of  interest,  and  locating  the  point(s)  of 
entry. 


1.2  BACKGROUND 

Illegal  international  border  crossings  into  the  United  States  through  man-made  tunnels  and  utility  cul¬ 
verts  have  become  more  prevalent.  In  particular,  the  border  between  Mexico  and  the  southwestern  United 
States  is  a  target  for  drug- smugglers  bringing  illegal  drugs  into  the  United  States.  Many  technological  and 
legal  problems  exist  in  detecting,  securing,  and  decommissioning  these  tunnels.  Often,  these  access  tunnels 
are  tens  to  hundreds  of  meters  long,  can  have  significant  elevation  gradients,  and  may  contain  water  and/or 
various  types  of  debris. 

There  are  several  categories  of  tunnels  being  built  to  gain  entry  into  the  U.S.,  widely  ranging  in  depth 
and  dimensions.  They  can  be  elaborate  (sophisticated,  symmetric,  professionally  engineered),  or  hastily 
built  (hand  dug,  shallow,  unreinforced).  Some  tunnels  are  designed  to  connect  into  city  storm  drain  sys¬ 
tems,  allowing  circumvention  of  the  border,  such  as  in  Nogales,  Arizona.  A  few  tunnels  have  been  docu¬ 
mented  to  be  over  a  mile  long.  The  extreme  variances  in  conditions  that  exist  within  the  tunnels,  and  the 
fact  that  many  are  used  sporadically,  make  identifying  their  existence  and  locating  access  points  a  difficult 
task. 

The  Department  of  Defense  (DoD)  has  three  combatant  commands  with  interests  in  tunnels,  both  do¬ 
mestically  and  abroad.  U.S.  Strategic  Command  (USSTRATCOM)  is  concerned  with  combating  weapons 
of  mass  destruction  (WMD).  U.S.  Central  Command’s  (USCENTCOM)  area  of  responsibility  (AOR)  in¬ 
cludes  current  areas  susceptible  to  tunneling  in  Iraq,  Afghanistan,  Egypt,  Israel,  and  potentially  other  coun¬ 
tries.  U.S.  Northern  Command’s  (USNORTHCOM)  mission  is  to  defend,  protect,  and  secure  the  United 
States  and  its  interests,  including  support  of  counter-drug  operations  and  managing  the  consequences  of 
terrorist  events  employing  WMDs.  USNORTHCOM’s  AOR  includes  the  U.S.,  Mexico,  and  Canada,  and 
providing  assistance  to  lead  law  enforcement  agencies  when  tasked  by  the  DoD.  This  project  developed  a 
capability  to  explore  tunnels  and  identify  the  entrances  to  illegal  tunnels  crossing  over  U.S.  borders,  and  to 
exploit  voids  within  theaters  of  operation  overseas. 

Previous  work  performed  with  robots  working  in  tunnels  and  mines  for  teleoperation  and  mapping 
and  has  been  leveraged  by  this  project.  Some  of  the  earlier  work,  documented  by  Laird  [1],  laid  out  some 
of  the  basic  vehicle  teleoperation  issues  for  tunnel  exploration  and  reconnaissance.  Mapping  tunnels  and 
mines  tends  to  be  difficult  because  of  the  relatively  nondescript  nature  of  the  walls,  which  is  why  many  of 
these  tunnel/mine-mapping  systems  integrate  lidars  into  their  localization  systems  [2].  Carnegie  Mellon 
University  (CMU)  used  a  nodding  lidar  and  registered  the  data  using  Simulataneous  Localization  and 
Mapping  (SLAM)  [3].  Other  mine-mapping  systems  have  used  stop/start  scanning  with  two-dimensional 
(2D)  lidars  [4]  which  involves  obstacle  avoidance  while  the  vehicle  is  moving,  then  stopping  to  allow  the 
robot  to  generate  a  stable  three-dimensional  (3D)  scan  of  the  environment.  This  3D  data  was  then  used 
with  Markov  Random  Lields,  an  A*  search,  and  C-space  maps  to  generate  3D  maps  and  plan  future  motion. 
Niichter  et  al.  [5]  discussed  a  3D  SLAM  algorithm  designed  to  handle  the  six  degrees  of  freedom  (6DoL) 
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inherent  in  a  subterranean  environment,  using  a  reduced  point  cloud  and  a  fast  iterative  closest  point  (ICP) 
variant  to  locally  and  globally  register  the  point  clouds. 

This  counter-tunnel  effort  was  funded  by  the  Joint  Ground  Robotics  Enterprise  (JGRE)  from  fiscal 
year  2010  through  2013,  run  jointly  by  SPAWAR  Systems  Center  (SSC)  Pacific  and  Air  Eorce  Robotics 
Laboratory  Airbase  Technologies  Division  (AFRL/RXQ)  Tyndall,  and  was  a  complementary  development 
effort  addressing  objective  requirements  to  the  Rapid  Reaction  Tunnel  Detection  (R2TD)  Joint  Capabil¬ 
ity  Technology  Demonstration  (JCTD),  managed  by  U.S.  Northern  Command  (USNORTHCOM).  This 
project  addresses  the  objective  tunnel  exploration  requirements  defined  for  the  R2TD  JCTD. 


1.3  OBJECTIVES  AND  SCOPE 

The  project  objective  is  to  develop  and  demonstrate  technologies  that  enable  insertion  of  a  robotic 
system  through  a  small  borehole  into  a  suspect  tunnel  cavity  to  conduct  precision  mapping  and  characteri¬ 
zation  operations  in  austere  tunnel  environments  (hand-dug  border  tunnels,  caves,  etc.). 

The  scope  of  the  effort  has  been  divided  into  three  major  technology  thrusts: 

1.  Development  of  an  Unmanned  Ground  Vehicle  (UGV)  mobility  platform  capable  of  insertion 
through  a  maximum  20-centimeter-diameter  borehole. 

2.  Development  of  a  borehole  deployment  capsule  to  support  insertion  and  retrieval  of  the  UGV  system 
and  provide  a  communications  relay  node  at  the  tunnel  insertion  point. 

3.  Development  of  a  perception  system  small  enough  to  fit  inside  the  borehole  deployment  capsule  and 
provide  localization,  obstacle  detection,  and  3D  mapping. 


1.4  SYSTEM  REQUIREMENTS 

•  Deploy  and  retrieve  a  UGV  through  a  20-centimeter  borehole  into  tunnels  3  to  30  meters  in  depth 

•  Transit  up  to  800-meter  round  trip 

•  Traverse  two  horizontal  45 -degree  turns 

•  Climb  a  30-centimeter  vertical  discontinuity  (i.e.,  a  step) 

•  Traverse  a  30-centimeter  gap  or  crevice 

•  Operate  over  varied  and  rough  terrain  including  mud,  loose  gravel,  areas  of  limited  traction,  and  up 
to  20  centimeters  of  standing  water 

•  Autonomously  explore,  localize,  and  map  the  tunnel 

•  Localize  the  entry  within  1  meter  of  accuracy 

•  Generate  a  3D  model  of  the  tunnel  environment  for  characterization,  measurement,  and  analysis 
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2.  BOREHOLE  DEPLOYMENT/RETRIEVAL  APPARATUS 


The  Borehole  Deployment/Retrieval  Apparatus  was  developed  by  the  Air  Force  Research  Laboratory 
Airbase  Technologies  Division  (AFRL/RXQ)  Tyndall  Robotics  Team,  its  main  purpose  being  to  deliver  the 
intended  UGV  platform,  the  Counter  Tunnel  Exploitation  Robot  (CTER),  through  a  20-centimeter  borehole 
to  depths  of  up  to  30  meters.  The  apparatus  is  composed  of  two  parts:  the  Robot  Delivery  Capsule  (RDC) 
and  the  Capsule  Support  Trailer. 

The  Robot  Delivery  Capsule,  in  Figures  1  and  2,  is  a  unique  system  that  safely  stores  the  CTER  during 
deployment  and  retrieval  through  a  20-centimeter  borehole.  The  Kearfott  KI-4901  inertial  measurement 
unit  (IMU)  aboard  the  RDC  provides  a  highly  accurate  initial  position  and  orientation  for  the  mapping 
sensor.  An  internal  winch  is  used  to  lower  and  raise  the  CTER  into  and  out  of  the  RDC.  A  clasping  device 
securely  holds  the  robot  in  place  during  this  operation,  keeping  the  robot  in  a  fixed  orientation  to  the  RDC 
for  transferring  the  initial  position  to  the  robot.  A  camera  and  light  at  the  end  of  the  RDC  helps  to  aid  the 
operator  execute  this  process. 


Figure  1.  Robot  Delivery  Capsule  (RDC)  model  with  labeled  parts. 


The  Capsule  Support  Trailer,  Figure  3,  also  includes  a  winch  to  raise  and  lower  the  RDC  to  the  ap¬ 
propriate  borehole  depths.  The  winch  cable  is  run  over  a  pulley  on  top  of  a  vertical  A-frame  mounted  on 
the  rear  of  the  trailer.  A  control  box  for  remote  control  of  the  RDC  as  well  as  the  trailer-mounted  winch  is 
located  near  the  tongue  of  the  trailer.  Supporting  stands  are  also  provided  on  the  trailer  for  stowage  of  the 
RDC  during  transport  of  the  system. 

The  trailer  instrumentation  monitors  weight  and  position  feedback  for  RDC  deployment.  A  generator 
mounted  on  the  trailer  provides  power  for  the  RDC,  the  trailer-mounted  winch,  the  system  control  box, 
and  any  command  and  control  computers  needed  for  the  system.  The  trailer  also  has  hand-cranked  lifts 
mounted  on  the  corners  to  level  the  trailer  prior  to  deployment  of  the  RDC. 
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Figure  2.  Robot  Delivery  Capsule  (RDC). 


Figure  3.  Capsule  Support  Trailer. 
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2.1  BOREHOLE  DEPLOYMENT/RETRIEVAL  APPARATUS  TESTING 


Engineers  conducted  suitability  and  functionality  testing  on  the  Borehole  Deployment/Retrieval  Ap¬ 
paratus,  including  the  Capsule  Support  Trailer  and  the  RDC.  They  tested  the  Deployment  Trailer’s  Sound 
Ocean  Systems,  Inc.  ECO  Winch  for  suitability  for  RDC  deployment.  The  winch  measurement  was  not 
used  for  cable  length  since  it  only  had  a  30-centimeter  resolution.  The  BEI  Sensors  H25  incremental  op¬ 
tical  encoder  was  used  to  verify  the  cable  length  readings  from  the  IMU  on  the  depth  of  the  tunnel  and  to 
provide  feedback  to  the  RDC  scripts  for  smooth  deployment  of  the  robot.  The  encoder  was  accurate  to 
within  0.25%  of  total  distance  traveled.  The  cable  management  and  A-frame  arms  were  sufficient  for  de¬ 
ployment  of  the  RDC.  Gigabit  multi-mode  fiber-optic  communication  and  48  VDC  power  were  passed  to 
the  RDC  through  the  winch  cable  via  a  slip  ring  provided  on  the  winch.  This  South  Bay  Cable  SB-47575 
has  a  working  load  strength  of  200  pounds  and  a  breaking  strength  of  1000  pounds.  A  Strainsert  Q21880 
clevis  bolt  served  as  the  axle  for  the  pulley  wheel  over  which  the  winch  cable  was  passed,  and  used  to  mea¬ 
sure  the  weight  on  the  cable  and  as  an  indicator  if  the  RDC  was  stuck  in  the  borehole.  Drive  current  to  the 
winch  motor  was  also  monitored  for  this  purpose  with  AcuAMP  ACT050  current  sensors.  The  control  box 
monitoring  all  of  the  information,  as  well  as  the  source  of  the  48  VDC  and  fiber-optic  cable  to  the  RDC, 
was  designed  and  built  by  AERL.  This  control  box  was  powered  by  1 15  VAC  and  used  Gigabit  Ethernet 
for  communications. 

The  Robot  Delivery  Capsule  was  designed  to  be  suitable  for  deployment/retrieval  of  the  CTER.  The 
RDC  holds  the  50-pound  CTER  in  a  fixed  position  with  a  safety  factor  of  six  (tested  to  hold  six  times  its 
weight).  The  Kearfott  IMU  provided  position  accuracy  within  0.1%  of  distance  traveled  from  its  initial 
position.  The  measured  roll  of  the  IMU  was  within  0.07  degrees  root-mean-square  (RMS),  pitch  was 
within  0.06  degrees  RMS,  and  yaw  was  within  0.03  degrees  RMS  of  actual  movement.  The  RDC  overall 
length  was  approximately  4  meters:  1.5  meters  for  the  electronics  and  internal  robot  attachment  and  2.5 
meters  for  CTER  storage  space.  The  top  portion  of  the  RDC  included  the  IMU,  an  embedded  computer, 
motor  controllers,  power  conditioning,  as  well  as  the  winch  to  insert  and  deploy  the  CTER  from  the  RDC. 
This  winch  connected  to  a  pendant  with  a  unique  grapple  mechanism  for  robot  attachment.  Inside  this 
pendant  was  a  fiber-optic  module  for  connection  to  the  CTER,  a  camera  and  lighting  for  operator  aware¬ 
ness,  and  power  conditioning.  A  unique  pattern  was  printed  and  attached  on  the  end  of  the  RDC,  used 
by  the  mapping  sensor  on  the  UGV  to  determine  its  starting  point  relative  to  the  RDC  for  localization  to 
the  world-coordinate  system  (see  Section  6.2).  A  custom  coil  cable  made  by  Woven  Electronics  intercon¬ 
nected  the  top  section  of  the  RDC  to  the  pendant.  This  cable  prevents  snags  on  the  internal  winch  cable  as 
well  as  protects  the  fiber-optic  and  copper  wires  in  the  cable. 
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3.  ROBOTIC  PLATFORMS 


3.1  PROTOTYPE  COUNTER  TUNNEL  EXPLOITATION  ROBOT  {CTER)  PLATFORM 

The  Counter  Tunnel  Exploitation  Robot  {CTER),  built  by  Raytheon  Sarcos  Integrated  Defense  Systems 
(IDS),  is  a  high  degree  of  freedom  (DOF)  UGV  designed  to  address  the  counter-tunnel  mission  as  shown 
in  Figures  4,  5,  and  6.  Two  of  these  platforms  were  delivered:  one  to  AFRL  Robotics  at  Tyndall  AFB,  FL, 
and  one  to  SSC  Pacific  Unmanned  Systems  Branch,  San  Diego,  CA. 

The  CTER  has  a  camera  mounted  on  arms  at  the  rear  of  the  aft  track,  which  can  rotate  180  degrees 
to  the  left  and  right  for  360-degree  viewing.  Arms  on  the  front  track  allow  for  payload  attachment.  The 
CTER  is  17  centimeters  wide  x  172  centimeters  long  x  17  centimeters  tall  (no  payload).  The  robot  features 
a  fiber-optic  communication  tether  that  provides  a  link  for  commands,  status,  video  feedback,  and  mapping 
sensor  data.  Wireless  communication  has  been  explored  for  this  application  and  a  solution  is  described 
in  Section  4.  The  CTER  has  an  on-board  real-time  controller  for  joint  control,  drive-motor  control,  and 
camera-image  compression.  The  unique  joints  and  motors  arrangement  between  the  tracks  of  the  CTER 
allow  for  step  climbing,  roll  prevention,  and  side-by-side  track  operation.  The  robot  is  also  designed  to 
be  submerged  in  up  to  20  centimeters  of  water  (although  no  submersion  tests  were  performed  during  this 
project). 

Multiple  drive  modes  are  available  to  the  robot  operator  including:  Eind  Zeroes,  Uncommanded,  Zero 
Torque,  Step  Climb,  Anti-Roll,  Bend,  Eollow-the-Leader,  Cobra,  and  Tank.  The  Eind  Zeroes  mode  is  the 
initialization  procedure  that  the  robot  needs  to  run  every  time  it  is  powered  on.  The  Uncommanded  and 
Zero  Torque  modes  disable  all  robot  motion,  and  allow  an  operator  to  manipulate  it  manually  with  no 
motor  driving.  Step  Climb  driving  mode  will  successfully  climb  30-centimeter  steps.  Anti-Roll  mode  is 
a  driving  mode  that  offsets  the  tracks  and  actively  corrects  for  roll.  If  a  condition  occurs  where  the  mode 
cannot  prevent  a  roll,  the  robot  will  go  into  the  Uncommanded  mode.  Bend  mode  is  a  driving  mode  that 
allows  the  operator  to  offset  the  tracks  at  varying  angles  in  order  to  provide  stability.  Preset  angles  of  15, 
30,  and  45  degrees  are  available.  When  rotating  in  this  mode,  the  tracks  turn  toward  each  other  in  a  C- 
shape.  Eollow-the-Leader  is  another  driving  mode  in  which  the  rear  track  attempts  to  follow  the  path  of  the 
front  track  exactly  (Figure  4).  Cobra  mode  raises  the  aft  track  in  order  to  give  the  camera  a  better  vantage 
point.  In  Tank  mode  (Figure  6),  the  robot  will  position  the  tracks  in  parallel  with  each  other  and  operate  as 
a  skid-steer  vehicle. 

3.1.1  CTE/?  Testing 

The  CTER  began  operation  in  February  2013  through  June  2013.  Engineers  evaluated  the  multiple 
driving  modes,  vehicle  mobility,  vehicle  run-time,  and  ease  in  deploying  and  retrieving  the  vehicle  from 
the  RDC. 

3.1. 1.1  Test:  Driving  Modes  and  Run  Times.  The  CTER  standard  driving  operation  is  as  follows: 

1.  Insert  fully  charged  batteries  into  front  and  rear  track  compartments  (front  battery  is  for  payloads, 
rear  battery  is  for  driving  motors). 

2.  Plug  in  the  fiber-optic  communication  cable  from  the  Operator  Control  Unit  (OCU)  to  the  connector 
in  the  rear  track  compartment. 

3.  Install  the  watertight  covers  over  both  battery  compartments. 

4.  Turn  on  the  power  to  both  front  and  rear  compartments  and  install  switch-hole  plug. 
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Figure  4.  CTER  platform  maneuvering  around  obstacles  in  a  narrow  tunnel  in  Follow-the-Leader 
mode. 


Figure  5.  CTER  platform  driving  into  a  23-centimeter  storm  drain. 
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Figure  6.  CTER  platform  in  Tank  mode  in  a  test  tunnel.  This  mode  was  used  to  turn  the  CTER 
around  in  narrow  passages  such  as  seen  here. 


5.  Turn  on  the  OCU  and  run  the  Find  Zeroes  mode  on  the  robot.  This  mode  initializes  the  robot  for 
operation. 

6.  Select  a  driving  mode  on  the  OCU  and  operate  the  robot 

The  vehicle  run  time  was  evaluated  for  each  driving  mode  in  a  straight  run,  flat  gravel  surface,  fully 
charged  battery,  no  payload  installed,  and  until  the  battery  was  completely  discharged,  with  results  shown 
in  Table  1 . 


Table  1 .  CTER  drive  times  and  distances  in  various  drive  modes. 


MODE 

DISTANCE 

TIME 

Anti-Roll 

1356  m 

69  min,  14  sec 

Bend 

1920  m 

115  min,  57  sec 

Follow-the-Leader 

2240  m 

112  min,  42  sec 

Tank 

2156  tn 

122  min,  32  sec 

The  Tank  mode  is  the  most  stable  of  all  the  drive  modes,  however  in  this  mode  the  payload  is  facing 
the  rear  of  the  robot.  The  Anti-Roll  mode  is  currently  tuned  to  prevent  roll  by  the  robot  in  the  basic  config¬ 
uration  with  no  payload.  Adding  a  payload  and  running  in  this  mode  causes  continual  overcorrection  by 
the  robot,  which  in  some  cases  causes  the  payload  to  hit  the  ground  on  both  sides  as  the  robot  oscillates 
about  the  roll  axis.  With  a  payload  installed,  tests  have  found  that  Bend  mode  and  Follow-the-Leader  mode 
provide  the  most  effective  driving. 
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The  Step  mode  of  the  robot  was  also  evaluated,  and  it  successfully  climbed  30-centimeter  steps,  al¬ 
though  the  steps  needed  to  have  a  front  face  for  the  tracks  to  drive  up.  The  robot  also  demonstrated  cross¬ 
ing  a  30-centimeter  gap  in  all  driving  modes. 

3.1. 1.2  Test:  Mobility.  The  mobility  testing  of  the  CTER  was  to  evaluate  its  ability  to  turn  around  in 
a  tunnel,  climb  up  and  down  30-centimeter  steps,  drive  in  91 -centimeter  culverts,  turn  around  in  91- 
centimeter  culverts,  drive  over  gaps  of  30  centimeters,  and  evaluate  effectiveness  of  fiber-optic  spools 
for  control  of  the  robot. 

Turning  the  CTER  around  in  a  small  space  was  very  challenging.  It  was  determined  when  driving  in 
Bend  or  Eollow-the-Leader  mode  that  putting  the  robot  in  Tank  mode,  turning  around,  and  returning  to  the 
previous  drive  mode  was  the  easiest  way  to  turn  around. 

The  CTER  could  climb  up  and  down  30-centimeter  steps.  However,  climbing  required  a  flat  floor 
surface  and  sufficient  floor-surface  friction.  Polished  concrete  provides  insufficient  friction  for  the  snake  to 
climb  the  stairs.  Plywood,  gravel,  and  carpet  were  all  adequate  floor  surfaces  to  allow  the  CTER  to  climb 
steps. 

Driving  in  91 -centimeter  round  culverts  was  successful  but  required  a  close  watch  on  the  roll  angle 
while  driving.  Since  the  culvert  had  no  reference  points  to  look  at  while  driving,  the  roll  indicator  was  the 
only  way  to  determine  if  the  CTER  was  driving  at  the  bottom  of  the  culvert.  Without  the  roll  indicator, 
rollovers  of  the  CTER  are  expected.  Turning  around  in  the  culvert  was  accomplished  using  Tank  mode. 

The  CTER  can  cross  30-centimeter  gaps  without  any  extra  effort.  Due  to  the  track  length  being  almost 
double  the  30-centimeter  gap  size,  there  was  no  visually  perceptible  drop  on  the  front  of  the  track  when 
crossing  a  30-centimeter  gap. 

The  CTER  platform  was  designed  to  use  fiber-optic  spools  for  communications.  Due  to  difficulties  in 
obtaining  properly  wound  fiber-optic  spools  before  the  test  events,  fiber  spool  testing  was  not  completed. 
All  of  the  tests  at  AFRL  were  accomplished  via  an  unspooled  823-meter  test  fiber-optic  cable. 

As  previously  mentioned,  the  CTER  is  a  prototype  robot  design,  built  to  meet  the  requirements  of 
delivery  through  a  20-centimeter  borehole,  driving  800  meters,  and  communicating  via  fiber-optics.  Al¬ 
though  this  platform  met  these  requirements,  there  were  some  observed  reliability  issues.  Both  of  the 
delivered  CTER  platforms  had  to  have  the  joints  of  the  center  section  replaced  as  a  result  of  cold  welding 
between  the  original  joints.  Additionally,  a  track  controller  circuit  board  had  to  be  replaced  due  to  a  failure. 
The  power-up  calibration  sequence  was  also  sometimes  problematic,  as  it  would  occasionally  initialize  in 
the  wrong  orientation.  This  would  then  require  a  reboot  and  rerun  of  the  calibration  sequence  until  it  was 
performed  correctly.  A  couple  months  after  initial  receipt  of  the  AFRL  CTER,  it  had  to  be  returned  to  the 
manufacturer  for  an  upgrade.  This  upgrade  put  a  real-time  controller  on  board  the  CTER  and  seemed  to 
improve  the  responsiveness  of  the  controls.  A  shipping  container  designed  specifically  for  the  CTER  was 
also  built  due  to  problems  encountered  during  shipping  of  the  CTER  at  SSC  Pacific.  The  time  required  for 
these  Axes  and  upgrades  greatly  limited  the  amount  of  time  available  for  subsequent  testing  and  evaluation 
of  the  CTER  platform. 

3.1. 1.3  Test:  Terrain  Maneuvers.  The  CTER  was  driven  over  varied  terrain  and  performed  well  (with¬ 
out  the  localization  and  mapping  payload).  Using  the  Anti-Roll  mode,  the  platform  was  able  to  drive  over 
gravel,  crushed  rock,  and  obstacles  such  as  pieces  of  2-  x  4-inch  lumber  without  tipping  over.  Large  obsta¬ 
cles  such  as  a  pile  of  15-  to  30-centimeter  rocks  were  found  to  be  too  difficult  for  the  CTER  to  navigate, 
and  climbing  over  these  obstacles  often  resulted  in  roll-over,  even  in  the  Anti-Roll  driving  mode.  In  other 
modes  such  as  Bend  and  Eollow-the-Leader,  the  snake  successfully  navigated  the  previously  mentioned 


9 


obstacles  but  required  care  to  prevent  tip-over.  When  tip-overs  did  occur,  operators  used  the  CTER'^  Roll 
mode  to  roll  the  robot  to  the  upright  position.  Corrugated  plastic  and  steel  also  presented  no  traversal 
problems. 

The  CTER  was  designed  to  withstand  submersion  in  up  to  20  centimeters  of  water,  although  this  could 
not  be  verified  because  water  tightness  of  the  CTER  was  only  accomplished  with  installation  of  a  fiber 
spool.  As  discussed  earlier  in  Section  3. 1.1. 2,  the  fiber  spools  were  not  delivered  in  time  for  testing  by 
AFRL. 


3.2  ALTERNATIVE  PLATFORMS 

SSC  Pacific  created  a  plan  to  use  alternative  robotic  platforms  for  testing  and  evaluation  of  sensors  and 
autonomy  algorithms,  to  continue  development  work  while  the  CTER  platform  was  being  prototyped  and 
upgraded.  Although  these  alternative  platforms  would  not  fit  through  a  20-centimeter  borehole,  they  could 
still  be  viable  options  for  ISR,  mapping,  and  characterization  of  tunnels  if  other  methods  of  entry  were 
available. 

3.2.1  iRobot®  PackBof 

The  iRobot®  PackBot®  was  the  primary  vehicle  for  sensor  and  autonomy  development.  SSC  Pacific 
has  used  the  PackBot®  in  various  other  projects  and  even  developed  a  teleoperation-to-autonomy  conver¬ 
sion  box  that  would  fit  inside  one  of  the  three  payload  bays,  complete  with  an  Intel  Dual  Core  processing 
board,  KVH  DSP -3000  fiber-optic  gyro,  MicroStrain  3DM-GX2  IMU,  with  USB  and  Ethernet  connec¬ 
tors.  Small  enough  to  fit  into  all  the  tunnels  that  were  explored,  the  PackBot®  provided  a  robust  wireless 
communication  link  without  any  additional  radios  attached.  The  PackBot®  is  52  centimeters  wide  x  89 
centimeters  long  x  17  centimeters  tall  (no  payload). 


Figure  7.  Pac/cSo/®  with  mounted  NREC  MultiSense-SL 
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3.2.2  RoboteX®  AVATAR®  II 


The  RoboteX®  AVATAR®  II  is  a  smaller  alternative  platform  to  the  PackBot®  but  offered  many  of  the 
same  capabilities  at  a  much  lower  cost  (Figure  8).  If  the  primary  user  of  these  systems  is  the  Customs 
and  Border  Protection,  under  current  fiscal  conditions  the  costs  of  the  entire  package  would  have  to  be 
reduced  significantly.  This  platform  served  as  a  mitigation  effort  for  that  risk.  The  biggest  concern  with 
this  platform  was  that  it  had  been  designed  for  teleoperation  only  and  was  not  ready  for  autonomous  con¬ 
trol.  SSC  Pacific  engineers  worked  with  RoboteX®  to  design  a  solution  for  an  integrated  controller  that 
would  accept  commands  for  velocity,  rotation,  flippers,  and  camera  rotation,  which  had  previously  only 
been  available  strictly  from  RoboteX® ’s  handheld  controller.  Integration  with  the  embedded  radios  on  the 
AVATAR®  II  was  not  feasible,  so  wireless  communications  required  an  additional  radio  attached  to  the  plat¬ 
form.  Wireless  control  and  perception-sensor  integration  of  this  platform  was  demonstrated  in  November 
2013  at  the  demonstration  and  test  near  the  international  border  of  California  south  of  San  Diego  (Section 
9.2).  Tho  AVATAR®  II  is  38  centimeters  wide  x  61  centimeters  long  x  15  centimeters  tall  (no  payload). 


Figure  8.  AVATAR®  II  mounted  with  sensors  and  radios. 


3.2.3  Unmanned  Aerial  Vehicles 

The  use  of  aerial  vehicles  was  outside  the  scope  of  the  Counter  Tunnel  effort,  but  based  on  experi¬ 
ences  gained  in  the  evaluation,  it  would  be  worth  exploring  their  use  in  tunnel  environments.  Based  on 
prior  work  completed  by  the  University  of  Pennsylvania  [6]  and  some  innovative  methods  of  quadrotor 
protection  demonstrated  with  the  Laboratory  of  Intelligent  Systems’  GimBall  [7]  or  the  Illinois  Institute 
of  Technology’s  Hytaq,  this  method  could  provide  a  quick  and  efficient  way  of  traversing  and  mapping 
tunnels.  Research  conducted  by  the  Jet  Propulsion  Laboratory  and  University  of  California  (UC)  Berkley 
demonstrates  the  capability  to  add  the  required  sensors  on  board  a  quadrotor  and  to  ingress  through  a  small 
rectangular  opening  like  a  window  [8].  The  potential  advantages  of  an  air  vehicle  are  further  reinforced  by 
issues  encountered  during  a  data  collection  of  a  cross-border  tunnel  where  the  PackBot®  was  continually 
jarring  up  and  down  from  the  makeshift  push-cart  tracks,  which  introduced  error  into  the  localization  solu¬ 
tion  (see  Section  9.3).  An  aerial  vehicle  could  fly  through  the  tunnel  and  collect  the  data  without  the  jerky 
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movements.  These  days,  prices  for  quadrotors  and  their  autopilots  have  come  down  significantly  and  can 
be  purchased  for  less  than  $1000  from  companies  such  as  UAir  or  SDRobotics. 
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4.  COMMUNICATIONS 


4.1  COMMUNICATIONS  REQUIREMENTS 

The  communication  requirements  of  the  Counter  Tunnel  project  included  controlling  the  UGV  for  a 
distance  of  400  meters  while  it  traversed  through  a  tunnel  that  had  two  45-degree  turns  and  an  additional 
90-degree  turn.  The  effective  communications  range  in  tunnel  applications  depends  on  several  factors 
that  fall  into  two  categories:  radio  characteristics  and  environmental  factors.  The  radio  characteristics  of 
greatest  importance  are  power  emitted,  RF  channel  bandwidth,  frequency,  and  antenna  selection.  The  en¬ 
vironmental  factors  are  distance  of  the  antenna  from  any  of  the  tunnel  surfaces  and  size,  shape,  curvature, 
and  material  composition  of  the  tunnel.  The  system-specific  constraints  include  space  allocated  for  the 
radio,  Ethernet  interface,  and  power  usage. 

The  environmental  factors  are  difficult  to  model  for  all  given  possibilities;  hence,  to  encompass  the 
variability  of  tunnel  environments,  testing  occurred  at  multiple  tunnels  chosen  to  represent  the  breadth  of 
tunnel  variability  that  the  system  could  experience. 


4.2  RADIO  SELECTION  TESTING 

The  radio- selection  test  tunnel  was  chosen  based  on  adherence  to  the  anticipated  environmental  factors 
that  the  system  would  experience.  The  propagation  effects  of  the  tunnel  were  tested  to  determine  the  cut¬ 
off  frequency  and  ideal  operating  frequency. 

SSC  Pacific  engineers  chose  a  tunnel  in  the  Twentynine  Palms  area  which  had  approximate  dimen¬ 
sions  of  1.5  meters  tall  by  0.9  meter  wide  (Figure  9a).  The  test  site  was  an  old  mining  tunnel,  built  by 
hand,  representative  of  the  target  environment.  Frequency  sweeps  were  performed  with  wide-band  logarith¬ 
mic  antennas  at  heights  of  0.9  meter  and  0.3  meter  respectively  at  various  distances  (Figure  9b).  A  plot  of 
the  results  is  shown  as  amplitude  vs.  frequency  in  Figure  10.  Additional  tests  were  conducted  at  the  Eagle 
mine  in  Julian,  CA  (Figures  12a  through  12c).  The  cutoff  frequency  for  this  test  was  600  MHz,  with  an 
optimal  frequency  of  approximately  1  to  1.3  GHz.  These  results  guided  the  initial  radio  selection. 


4.3  RADIO  SELECTION 

The  chosen  radios  that  meet  the  initial  space  allocation  and  power  usage  were  Silvus  4x4  MIMO  radio 
at  2  watts  and  1.3  GHz,  Trellisware  Wildcat  II  unit  at  8  watts  at  1.8  GHz,  and  Cobham  Mini-IP  radio  at  2.4 
GHz  (the  1-GHz  version  was  unavailable). 


4.4  RADIO  TESTING 

The  radio  testing  consisted  of  transmitting  1  Mbps  of  data  from  the  distant  node  to  the  base  station 
that  would  simulate  video  data.  The  distant  node  was  also  transmitting  approximately  80  Kbps  of  data  that 
would  simulate  command  and  control  data.  The  base  station  antenna  was  approximately  0.9  meter  off  the 
ground,  while  the  distant  node  antenna  was  approximately  0.3  meter  off  the  ground.  SSC  Pacific  engineers 
conducted  the  tests  at  the  Twentynine  Palms  test  mine  and  the  Julian  Eagle  Mine.  The  Twentynine  Palms 
test  mine  included  one  distinct  45-degree  bend.  The  maximum  range  results  of  the  selected  radios  at  Twen¬ 
tynine  Palms  were  as  follows:  Trellisware  -  122  meters,  Cobham  -  106  meters,  and  Silvus  -  100  meters. 
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(a)  (b) 


Figure  9.  (a)  Twentynine  Palms  test  mine  opening,  (b)  Antenna  used  in  the  communication  test  at 
Twentynine  Palms  test  mine. 
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Figure  10.  Plot  of  amplitude  vs.  frequency  for  wireless  communication  tests. 


(a)  (b)  (c) 

Figure  11.  (a)  Silvus  radio,  (b)  Trellisware  radio,  and  (c)  Cobham  radio. 
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respectively.  The  Julian  Eagle  Mine  (Figures  12a  through  12c)  is  a  tunnel  with  a  91 -meter  straight  section 
followed  by  a  90-degree  turn  with  an  additional  30-meter  section,  followed  by  an  additional  90-degree  turn. 
All  three  radios  maintained  communications  for  122  meters  at  the  Julian  mine,  which  included  the  two 
90-degree  turns.  However,  the  Trellisware  radio  traversed  an  additional  1.8  meters  after  the  last  bend. 


Figure  12.  (a)  Entrance,  (b)  tunnel,  and  (c)  shoring  of  the  Eagle  Mine  in  Julian,  CA. 


4.5  RADIO  DOWNSELECT 

The  testing  results  did  not  provide  a  substantially  superior  radio  solution.  The  Trellisware  radios 
required  a  purchase  of  10  radios  due  to  production  costs,  which  was  prohibitive.  Alteration  of  the  space 
allocation  during  the  manufacturing  process  for  the  CTER  made  the  Silvus  Radios  no  longer  a  feasible 
option.  The  tested  Cobham  radios  were  on  loan  and  did  not  operate  at  the  optimum  frequency.  Hence, 
engineers  assumed  performance  of  these  radios  would  improve  at  the  alternate  frequency  and  this  solution 
was  chosen. 
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5.  PERCEPTION 


The  Counter  Tunnel  project  had  perception  requirements  to  localize  the  egress  points  within  a  meter  of 
accuracy  after  traversing  400  meters  without  Global  Positioning  System  (GPS)  and  to  create  a  3D  model  of 
the  tunnel  environment  for  obstacle  avoidance,  characterization,  measurement,  and  analysis.  A  3D  model 
is  especially  important  for  obstacle  avoidance  because  the  tunnel  environment  is  so  varied,  consisting  of 
stairs,  rocks  and  debris,  rail  and  cart  system,  etc.  This  perception  sensor  design  task  was  fulfilled  by  the 
National  Robotics  Engineering  Center  (NREC)  with  their  prototype  3D  sensor  system,  now  called  the 
MultiSense-SL. 


5.1  PERCEPTION  SENSOR 

SSC  Pacific  chose  the  National  Robotics  Engineering  Center  (NREC)  as  the  contractor  to  develop 
the  prototype  3D  sensor  system  to  meet  the  localization  and  mapping  requirements  in  a  small  package. 
After  evaluating  various  perception  sensors  such  as  flash  lidar,  time  of  flight  (TOE)  lidar,  phase  shift  lidar, 
scanning  radar,  stereo  cameras,  and  structured  light,  NREC  chose  to  develop  a  combined  TOE  lidar  and 
stereo  camera  sensor. 


Figure  13.  NREC  MultiSense-SL  perception  sensor  includes  a  rotating  lidar,  stereo  cameras,  and 
strobing  LED  lights. 

The  MultiSense-SL,  Eigure  13,  uses  an  axially  spinning  Hokuyo  UTM-30LX-EW  rotating  about  the  z 
longitudinal  axis,  an  optimal  view  for  tunnels,  which  is  calibrated  with  the  left  camera  of  the  stereo  pair. 
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Four  strobing  LED  lights  surrounding  the  sensor  provide  enough  lighting  for  accurate  stereo  camera  anal¬ 
ysis  in  no-  or  low-light  conditions,  such  as  inside  a  tunnel.  The  software  (a  hardened  computing  box  with 
an  Intel  Core  i7  processor)  computes  the  position  estimate  through  visual  odometry  (VO)  from  the  stereo 
cameras  at  10  Hz  and  a  position  correction  from  the  iterative  closest  point  (ICP)  algorithm  from  the  lidar 
at  3  Hz.  On  a  side  note,  teams  competing  in  the  Defense  Advanced  Research  Projects  Agency  (DARPA) 
Robotics  Challenge  (DRC)  in  track  B  and  C  used  this  sensor;  DRC  track  B  and  C  teams  competed  in  a 
software-only  challenge  where  winners  received  funding  and  an  assignment  of  the  Government  furnished 
Boston  Dynamics  Atlas  robot  with  a  MultiSense-SL  sensor  head. 

SSC  Pacific’s  tests  demonstrated  that  the  MultiSense-SL  provided  an  accurate  3D  point  cloud  repre¬ 
sentation  of  indoor  and  outdoor  environments,  tunnels,  buildings,  and  lab  spaces  (see  Figures  14  and  15). 
However,  because  visual  odometry  is  the  primary  localization  method  used,  position  estimation  becomes 
noisy  and  cannot  recover  when  it  has  no  visual  features  to  detect  or  track  (e.g.,  within  a  few  centimeters  to 
a  wall). 


Figure  14.  Top-down  view  of  a  point  cloud  of  lab  buildings,  captured  and  stitched  together  from  the 
MultiSense-SL  sensor. 
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Figure  15.  Point  cloud  of  lab  space,  captured  and  stitched  together  from  the  MultiSense-SL  sensor. 
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6.  LOCALIZATION  AND  MAPPING 

The  robotic  vehicles  operating  inside  a  tunnel  must  perform  in  a  GPS-denied  environment,  mapping, 
localizing,  and  providing  a  georeferenced  position  of  the  egress  points  at  more  than  400  meters  from 
the  entry  with  a  maximum  error  of  1  meter.  This  performance  level  requires  accurate  measurements  and 
tightly  coupled  solutions  to  the  localization  problems.  The  diagram  in  Figure  16  illustrates  the  challenges 
for  the  whole  system:  GPS  readings  will  be  captured  at  the  entry  point  of  the  borehole;  the  orientation, 
angle,  and  distance  of  the  Borehole  Deployment/Retrieval  Apparatus  needs  to  be  calculated  while  moving 
through  the  borehole;  the  vehicle  must  localize  itself  with  respect  to  the  Borehole  Deployment/Retrieval 
Apparatus  once  it  has  been  deployed;  and  finally  the  vehicle  will  need  to  accurately  calculate  its  odometry 
through  the  tunnel. 


Total  error  of  1  m  includes  GPS  error  on 
borehole  entry  point 
+  initial  georeferenced  position  and 
orientation  of  robot  deployed  from  the 
borehole 

+  vehicle  localization  error  (over  400  m 
tunnel  length) 


GPS  error 


Vehicle  localization  error 


Initial  robot  georeferenced 
position  and  orientation  error 
when  deployed  from  borehole 


Figure  16.  System  localization  error. 


6.1  BOREHOLE  APPARATUS  LOCALIZATION 

One  of  the  challenges  in  creating  an  accurate  georeferenced  3D  map  of  a  tunnel  is  obtaining  an  initial 
geospatial  location  and  orientation.  This  initial  pose  anchors  the  3D  map  in  reference  to  known  locations 
on  earth  and  without  an  accurate  estimate,  the  projection  of  the  tunnel  and  most  particularly  the  exit  points 
may  have  a  high  degree  of  error.  The  majority  of  geospatial  location  devices  use  GPS,  but  the  tunnel  en¬ 
vironment,  which  may  be  as  much  as  30  meters  below  the  surface,  prevents  GPS  units  from  functioning 
effectively  due  to  the  weak  signal  received  at  those  depths.  SSC  Pacific  needed  to  find  a  positioning  sys¬ 
tem  that  can  take  a  geospatial  position  while  on  the  surface  of  the  borehole  and  calculate  the  change  in 
position  as  the  delivery  capsule  descends  through  the  borehole.  The  position  system  also  had  to  meet  cer¬ 
tain  technical  specifications  that  are  described  in  Table  2,  showing  the  comparison  of  the  specifications  of 
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the  desired  versus  the  chosen  system.  The  unit  meets  all  the  specifications  was  the  Kearfott  KI-4901  T-24 
inertial  navigation  unit  (INU). 

Table  2.  Kearfott  INU  specifications  versus  requirements. 


Specification 

System  Requirement 

Kearfott  Kl-4901  T-24  INU 

North  Finding  Capability 

Yes 

Yes 

Position  Accuracy 

<  0.5%  of  distance  traveled, 
CEP 

<  0.1%  of  distance  traveled,  CEP 

Orientation  Accuracy 

<  1 .0  mils  (1  sigma) 

Heading  <  1.0  mil 

Roll/Pitch  0.5  mils 

Unaided  Alignment  Time 

<  30  min. 

<  15  min. 

Temperature  Range 

-40  °C  to  55  °C 

-40  °C  to  55  °C 

Allowable  Dimensions 

0.1 54  m  diameter  x  0.406  m 
length 

IMU:  0.1 14  m  diameter  x  0.160  m 
length 

CCA:  0.133  m  length  x  0.108  m 
width  X  0.018  m  depth 

CEP  =  Circular  Error  Probable 
IMU  =  Inertial  Measurement  Unit 
CCA  =  Circuit  Card  Assembly 


The  Kearfott  Kl-4901  T-24  INU  is  composed  of  an  inertial  measurement  unit  (IMU),  a  Circuit  Card 
Assembly  (CCA)  that  contains  the  processor  and  support  electronics,  and  a  power  supply  and  DC-DC 
converter.  Prior  to  alignment,  the  Kearfott  INU  requires  a  position  input,  which  can  be  provided  using 
GPS  or  through  a  geodetic  survey  over  the  center  of  the  borehole  at  surface  level.  Once  the  Kearfott  INU 
receives  the  known  position,  normal  alignment  begins.  With  the  unit  stationary,  the  alignment  process 
takes  15  minutes  before  pose  information  is  available.  Detection  of  excessive  motion  on  the  Kearfott  INU 
halts  alignment.  Once  aligned,  navigation  can  proceed.  Since  no  GPS  position  updates  will  be  available 
when  the  capsule  goes  down  the  borehole,  the  INU  is  solely  responsible  for  calculating  the  capsule’s  cur¬ 
rent  pose.  Due  to  the  gyro  drift  and  accelerometer  bias  errors  growing  over  time.  Zero  Velocity  Updates 
(ZUPT),  initiated  whenever  the  capsule  is  stationary,  need  to  be  performed  to  keep  the  pose  accuracy 
within  limits. 

6.1.1  Kearfott  Accuracy  Test  Results 

Prior  to  using  the  Kearfott  INU  for  calculating  the  RDC  reference  initial  pose,  the  INU  was  bench- 
marked  for  accuracy.  The  accuracy  test  results  showed  that  the  unit  performed  to  specifications. 

The  accuracy  tests  revealed  that  using  the  default  Zero  Velocity  Update  (ZUPT)  interval  of  30  seconds 
gave  the  best  results  for  both  2D  and  3D  position  accuracy  as  well  as  orientation  accuracy.  When  operators 
did  not  use  ZUPTs,  pose  solutions  drifted  to  the  point  of  being  unusable.  Constraining  the  rotational  move¬ 
ment  of  the  capsule  during  borehole  traversal  provided  a  tighter  pose  solution.  The  data  from  these  tests 
are  presented  in  Table  3. 

6.1.2  Borehole  Insertion  Testing 

Prior  to  borehole  insertion,  the  Kearfott  INU  had  to  perform  alignment  after  receiving  an  initial  GPS 
position,  a  process  that  took  15  minutes  to  complete.  The  long  alignment  period  makes  it  crucial  to  avoid 
capsule  movement  during  the  process.  Once  aligned,  pose  data  was  collected  when  the  capsule  was  at 
home  position  prior  to  movement;  at  ZUPT  stop  positions;  and  touching  the  bottom  of  tunnel  floor.  The 
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Table  3.  Kearfott  accuracy  test  data  (azimuth,  pitch,  and  roll  measurements  are  in  degrees). 


Te^t  Run 

Dur^tipn  (min) 

Distance  (m] 

ZUPT  interval  {sec) 

2  D  error 

3D  error 

dAzimuth 

dPitch 

dllgll 

Stfttic2 

■0 

30 

0.000 

0.000 

0.006 

0 

0 

HorizontalJ 

1090 

NO  ZUPT 

iie.99i 

119.310 

0 

0.141 

0.056 

32.00 

1090 

30 

0.074 

0-080 

0.011 

-0,118 

-0.073 

!H{>rizontak4 

i4.es 

1090 

60 

0.030 

0.100 

-0.006 

0.051 

‘0.017 

Horiz(?ntil5 

12.33 

1090 

120 

0,296 

0,296 

^0.005 

0.029 

0.022 

V<rticall 

6,51 

23 

NO  2LIPT 

15.213 

15.974 

0 

0.422 

0.309 

V«iiical5 

31  31 

32 

30 

0.323 

0.356 

-0.022 

-0.371 

0321 

yfirtical^ 

23.25 

26 

60 

0,199 

1,341 

-0.006 

-0.14 

-0.371 

Verticals 

23.7E 

40 

120 

O.S43 

Q.S49 

-O.CK35 

0709 

0.377 

difference  in  horizontal  position  (latitude  and  longitude)  from  the  home  position  to  the  tunnel  floor  po¬ 
sition  during  testing  was  4  millimeters.  The  total  vertical  travel  calculated  by  the  INU  was  3.52  meters 
compared  to  the  3.5  meters  reported  by  the  winch  encoder.  A  6-degree  change  in  the  yaw  was  attributed  to 
the  capsule  experiencing  minor  rotation  as  it  went  down  the  borehole.  Roll  and  pitch  values  varied  by  0.3 
degrees. 


6.2  FIDUCIAL  LOCALIZATION 

Once  the  vehicle  deploys  from  the  Borehole  Deployment/Retrieval  Apparatus,  it  localizes  itself  with 
the  apparatus,  which  has  already  localized  with  the  surface  coordinate  system  (normally  GPS).  The  vehicle 
does  this  by  first  detecting  the  exposed  portion  of  the  deployment  apparatus  using  a  rotationally  invariant 
localization  fiducial  attached  to  the  tip  of  the  apparatus  (Figure  17).  References  for  this  technique  are  in  [9] 
and  [10].  With  the  known  size  and  pattern  of  the  localization  fiducial,  the  vehicle  can  then  calculate  its  six 
degrees  of  freedom  position  and  orientation  using  only  a  single  image  from  a  single  camera.  This  position 
and  orientation  can  then  transform  through  the  known  apparatus  coordinate  frame  to  localize  the  vehicle 
with  the  surface  coordinates. 

6.2.1  Fiducial  Pattern 

The  localization  pattern  is  composed  of  black  or  white  circles  inscribed  within  oppositely  colored 
black  or  white  squares.  This  allows  the  pattern  to  contain  binary  data  as  well  as  be  easily  localized  using 
calibration  techniques.  In  the  cylindrical  case,  the  encoded  data  can  encode  the  yaw  rotation  of  the  pattern 
as  viewed  from  different  vantage  points.  In  the  flat  case,  the  bits  can  encode  the  unique  identification  of 
the  pattern,  allowing  large-scale  localization  with  multiple  patterns.  In  either  case,  the  pattern  needs  to  be 
rotationally  unique,  e.g.,  no  rotation  of  the  pattern  can  equal  itself  or  any  other  pattern.  In  the  cylindrical 
case  (Figures  ??  and  19),  every  view  of  the  pattern  needs  to  be  rotational  unique.  If  this  uniqueness  dis¬ 
continues,  localization  ambiguities  will  arise,  allowing  for  multiple  possible  solutions.  Ensuring  that  the 
patterns  are  greatly  different  from  each  other  allows  for  some  additional  error  checking.  To  achieve  this 
critical  uniqueness,  the  targets  use  a  solid  strip  of  black  or  white  circles  on  the  bottom  and  an  alternating 
pattern  on  top  (Figure  20). 
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Figure  1 7.  Deployment  of  the  CTER  platform  through  the  Borehole  Deployment/Retrieval  Apparatus 
with  attached  localization  fiducial. 


Figure  18.  5  x  8  cylindrical  fiducial  pattern. 
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Figure  20.  10x10  planar  fiducial  pattern. 


6.2.2  Localization  Aigorithm 

The  localization  algorithm  calculates  the  relative  position  of  the  origin  of  the  image  with  respect  to  the 
pattern.  The  algorithm  first  detects  possible  bits  using  a  contour  detection  algorithm.  Contours  detected 
between  two  threshold  values  and  contours  at  multiple  threshold  levels,  and  which  are  sufficiently  convex, 
are  added  as  potential  pattern  bits.  Figure  21  shows  contour  detection  run  on  a  cylindrical  pattern.  The  val¬ 
ues  of  the  threshold  minimum  and  maximum,  as  well  as  the  threshold  step,  determine  which  intermediate 
threshold  values  are  used.  Larger  ranges  and  smaller  steps  will  make  the  detection  algorithm  more  sensi¬ 
tive  but  take  more  time  to  process,  whereas  tighter  ranges  and  larger  steps  will  be  faster  but  may  miss  some 
of  the  pattern  bits.  Once  the  potential  bits  are  detected,  they  are  clustered  using  hierarchical  clustering  over 
both  location  and  contour  diameter.  The  largest  clusters  detect  the  presence  of  a  bit  pattern  and  organize 
the  bits  into  a  grid  structure. 

The  algorithm  compares  the  grid  to  the  pattern  using  different  rotations  and  different  shifts.  Figures  22 
and  23  illustrate  matching  on  cylindrical  patterns.  In  the  cylindrical  case,  these  shifts  translate  to  rotations 
about  the  cylinder.  The  rotation  and  shift  with  the  greatest  number  of  fully  matched  columns  is  used  for 
localization.  In  a  cylinder,  the  columns  are  the  only  fully  visible  portions  of  the  pattern.  Ties  are  broken  by 
the  total  number  of  bits  matched.  Perspective-n-Point  camera  pose  estimation  performs  on  the  pixel  loca¬ 
tions  and  the  matched  patterns’  3D  model  points,  resulting  in  a  full  six  degrees  of  freedom  transform  from 
the  image  to  the  pattern.  Mean  reprojection  error  is  used  to  break  any  remaining  ties.  When  using  multiple 
unique  patterns,  each  potential  pattern  can  be  matched  and  ties  can  be  broken  as  previously  mentioned  to 
determine  which  pattern  matches  best.  This  transform  can  be  combined  with  the  known  global  pose  of  the 
pattern  to  determine  the  global  pose  of  the  image.  A  brief  overview  of  the  algorithm  is  shown  in  Algorithm 
1. 
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Algorithm  1  Calculate  image  pose  using  fiducial  pattern. 

Require:  Image^  Pattern^  Models  ModelPose 
ImageBits  :=  BlobFinder(/ma^e) 
while  size{ImageBits)  >  0  do 

BitsOf  Interest  :=  HierachicalCluster(/ma^eSits) 

Grid  :=  DetectFattem(BitsO  f  Interest); 

[M appingcrid^ Patterns  C olumnM atehes ^  BitMatehes]  \=  FindBestMatching(Gri(i,  Pattern) 
if  ColumnMatehes  >  M axC olumnM atehes  or  C olumnM atehes  —  M axC olumnM atehes 
and  BitMatehes  >  M axBitM atehes  then 
MaxC  olumnM  atehes  ColumnMatehes 

M axBitM atehes  :=  BitMatehes 

[ImagePose^  ReprojeetionError]  —  PnP{GridBits^  M appingGrid^Pattem^  Model) 

end  if 

ImageBits  :=  ImageBits  —  BitsOf  Interest 

end  while 

ImagePose  ImagePose  +  ModelPose 
return  ImagePose^  ReprojeetionError 


Figure  21 .  Contour  detection  on  cylindrical  fiducial  pattern  in  mock  tunnel. 
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Figure  22.  Fiducial  matching  to  a  cylindrical  pattern. 


Figure  23.  Fiducial  matching  to  a  tilted  cylindrical  pattern. 
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6.2.3  Fiducial  Localization  Testing 

Tests  of  this  method  produced  results  that  were  within  1-  to  3-centimeter  accuracy  and  less  than  1- 
degree  azimuth  angle  error.  These  results  were  determined  using  the  camera  images  from  the  MultiSense- 
SL  and  the  lidar  scans  from  the  same  sensor  as  ground  truth.  The  authors  postponed  more  thorough  testing 
of  the  fiducial  system  to  implement  an  April  Tags  [9]  solution  for  comparison.  However,  time  and  budget 
restrictions  did  not  allow  for  additional  localization  implementations  or  more  thorough  testing. 


6.3  VEHICLE  LOCALIZATION 

The  MultiSense-SL  was  designed  to  provide  perception  and  localization  for  the  system,  but  when  the 
CTER  platform  and  the  MultiSense-SL  sensor  were  delivered,  integration  testing  showed  significantly 
degraded  mobility  performance.  The  CTER  platform  was  very  unstable  with  the  NREC  sensor  mounted 
on  the  arms  of  the  front  tracks,  often  causing  tip-over.  A  second  generation  of  sensor  miniaturization 
was  planned  but  didn’t  go  forward  due  to  budget  cuts.  During  testing,  engineers  used  the  Roll  mode  to 
self-right  the  platform  after  tip-over,  but  the  drive  gear  of  a  bender  joint  broke  a  tooth  due  to  the  weight 
of  the  sensor  and  the  robot  went  back  for  repairs.  Due  to  this  instability,  localization  and  mapping  tests 
were  conducted  solely  with  the  PackBot®  platform  and  not  on  the  CTER.  An  alternative  2D  simultaneous 
localization  and  mapping  (SLAM)  solution  was  tested  in  parallel. 

6.3.1  MultiSense-SL  Localization 

Localization  tests  conducted  with  the  MultiSense-SL  sensor  mounted  to  the  PackBot®  platform  pro¬ 
duced  positive  results.  The  localization  from  the  sensor  is  produced  from  the  visual  odometry  algorithm 
from  the  stereo  vision  cameras  and  corrected  with  an  ICP  algorithm  from  the  lidar  data.  No  formal  charac¬ 
terization  of  the  accuracy  of  the  localization  of  the  MultiSense-SL  sensor  was  performed  due  to  budget  and 
time  issues.  SSC  Pacific  ran  an  informal  test  of  the  sensor  mounted  on  a  PackBot®  multiple  times  inside  a 
1.5-meter-diameter  concrete  storm  drain,  driving  450  meters  in  and  450  meters  out  (a  total  of  900  meters 
traveled),  including  a  bend  of  90  degrees,  and  the  x,y-position  error  after  returning  to  the  original  location 
(based  on  MultiSense-SL  odometry  only),  was  0.9  meter.  This  was  an  impressive  feat,  especially  because 
the  visual  features  in  a  concrete  storm  drain  are  sparse,  as  shown  in  Ligure  24.  The  storm  drain  with  a 
manhole  access  point  can  be  seen  in  Figure  25a  and  as  a  registered  point  cloud  in  Figure  25b. 

6.3.2  Alternative  2D  Mapping  Localization 

The  CTER  platform  could  not  safely  manage  the  weight  of  the  MultiSense-SL  without  becoming  unsta¬ 
ble  and  tipping  over,  so  AFRL  developed  a  2D  mapping  system  using  a  Hokuyo  UTM-30LX  lidar  mounted 
on  the  CTER  (Figure  26)  and  used  SLAM  open  source  software  Hector  Mapping,  found  in  the  Robot 
Operating  System  (ROS).  The  test  setup  and  test  are  described  below. 

6.3.2. 1  2D  Mapping  Test  Setup.  AFRL  performed  the  mapping  test  using  a  Hokuyo  UTM-30LX  scan¬ 
ning  laser  mounted  on  the  CTER.  The  sensor  data  was  passed  to  a  laptop  running  ROS  (Robot  Operating 
System)  and  using  Hector  Mapping  for  SLAM.  Hector  Mapping  is  a  method  to  perform  SLAM  using 
only  a  horizontal  lidar  scan  and  no  odometry  information.  A  9-  to  36-VDC  to  12-VDC  converter  supplied 
power  to  the  Hokuyo  using  a  25-VDC  lithium-ion  battery  stored  in  the  front  track  compartment  of  the 
CTER.  The  battery  prevented  extra  power  draw  on  the  CTER  and  thus  extended  the  range  of  the  robot. 
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Figure  24.  MultiSense-SL  mounted  on  a  PackBofi’  mapping  and  localizing  in  a  concrete  storm 
drain. 


(a)  (b) 

Figure  25.  (a)  An  over-the-shoulder  view  of  the  PackBol®  in  the  storm  drain  pipe  with  a  manhole 
access  point,  (b)  A  registered  point  cloud  of  the  same  manhole  as  perceived  by  the  MultiSense-SL 
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Figure  26.  CTER  platform  with  mounted  Hokuyo  lidar  sensor  (lower  left). 


AFRL  performed  two  tests  with  the  2D  sensor.  For  the  first  test,  the  CTER  and  mounted  sensor  were 
loaded  on  a  cart  and  pushed  manually  around  the  robotics  fabrication  facility.  This  test  verified  operation 
of  the  sensor  mounted  on  the  snake,  and  ensured  the  SLAM  software  worked  properly.  For  the  second  test, 
the  CTER  was  teleoperated  through  a  mock  tunnel. 

6.3.2.22D  Mapping  Test  Results.  The  initial  test  of  the  sensor  was  performed  by  pushing  the  CTER 
on  a  cart  to  verify  operation  was  successful.  This  test  verified  that  battery  life  was  sufficient  to  keep  the 
sensor  running  for  at  least  as  long  as  the  CTER's  endurance.  Also  verified  were  proper  operation  of  the 
computer  and  software  that  were  performing  SLAM  based  on  the  laser  scanner  data.  This  test  included 
large  open  spaces,  office  spaces,  and  various  equipment  and  obstacle  features.  The  interior  layout  of  this 
building  allowed  for  a  loop  to  be  made  inside  of  the  building.  While  it  was  known  prior  to  this  test  that 
Hector  Mapping  does  not  perform  loop  closure,  it  proved  to  be  accurate  enough  for  most  situations.  The 
lack  of  loop  closure  was  evident  during  this  test,  as  loops  around  the  fabrication  facility  resulted  in  errors 
as  seen  in  Figure  27. 

AFRL  performed  the  second  test  of  the  sensor  in  a  mock  tunnel  environment.  This  test  highlighted  the 
issues  of  using  2D  mapping  for  this  application.  The  test  run  was  a  single  loop  around  the  test  tunnel.  The 
mock  tunnel  had  sections  of  smooth  concrete  walls,  walls  with  regularly  spaced  supports,  and  walls  with 
random  rock,  wood,  and  trash  features.  The  floor  variations  included  smooth  concrete,  crushed  rock,  dirt, 
and  sections  of  91 -centimeter  culvert  (concrete,  steel,  and  PVC).  Aluminum  covered  the  top  of  the  non¬ 
culvert  portions  of  the  mock  tunnel.  These  varied  terrain  features  simulated  multiple  types  of  tunnels  that 
Border  Patrol  officers,  law  enforcement,  or  warfighters  may  encounter  during  counter-tunnel  operations. 
Ensuring  that  the  sensor  was  facing  forward  was  essential  during  this  test.  Since  there  was  no  angular 
feedback  on  the  CTER  front  arms  (laser  mounting  location),  this  had  to  be  set  prior  to  running  the  test.  The 
specular  aluminum  ceiling  of  the  tunnel  caused  reflections  and  inaccuracies  in  the  reported  distance  of 
the  laser  scans.  It  was  also  very  evident  that  Hector  Mapping  was  not  sufficient  for  mapping  areas  with 
smooth  walls  or  regularly  spaced  supports.  Figure  28  shows  the  SLAM  output  became  confused  while 
mapping  these  types  of  surfaces.  The  Hector  Mapping  SLAM  algorithm  determined  that  the  robot  had  not 
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Figure  27.  Lab  facilities  map  created  by  Hector  Mapping  with  errors  from  loop  closure. 
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Figure  28.  Localization  error  (an  obstacle  was  placed  across  the  left-turn  entrance)  from  Hector 
Mapping  due  to  the  featureless  smooth  walls  in  tunnel. 


moved,  when  in  reality  it  had,  and  updated  the  map  showing  a  wall  across  the  entrance  to  a  turn  to  the  left. 
This  misinterpretation  was  due  to  the  wall  not  having  sufficient  features  for  the  laser  to  distinguish. 


6.4  SLIDE  IMAGES 

SSC  Pacific  explored  the  use  of  slide  images,  a  tunnel-based  point  descriptor  algorithm,  which  uses 
the  central  axis  of  the  tunnel  to  construct  a  radial  histogram  of  the  tunnel  walls,  as  a  method  of  loop  clo¬ 
sure  and  initial  localization.  This  histogram  provides  a  frame-independent  feature,  because  it  is  calculated 
relative  to  the  central  axis  as  opposed  to  a  synthetic  coordinate  system.  This  approach  requires  the  central 
axis  of  the  tunnel  be  estimated  from  the  available  point  cloud  data.  Once  estimated,  the  point  data  around 
each  portion  of  this  axis  is  segmented  and  binned  to  calculate  the  histogram.  More  information  concerning 
this  technique  is  found  in  [11]  and  [12].  In  Figure  29,  a  small  portion  of  tunnel,  shown  in  blue,  was  used  to 
estimate  the  central  axis,  shown  in  red.  This  segmented  data,  shown  in  green,  produces  a  series  of  slide  im¬ 
ages.  Using  the  gravity  vector  as  another  frame-independent  reference  point  (shown  in  green  in  Figure  30), 
the  distance  from  the  axis  (the  length  of  the  red  vector)  and  the  angle  about  the  axis  (the  angle  between 
the  green  and  red  vectors)  were  used  to  bin  the  individual  points.  This  histogram  was  then  blurred,  using 
a  standard  Gaussian  kernel,  to  dampen  the  effects  of  noise  in  the  point  data.  Figure  31  shows  a  completed 
slide  image  with  the  y-axis  bins  showing  the  angle  about  the  y-axis  and  the  x-axis  bins  showing  the  radius 
from  the  central-axis. 

SSC  Pacific  tested  a  localization  estimation  using  slide  images  against  an  iterative  closest  point  (ICP) 
algorithm  initialized  using  the  centroids  of  the  point  clouds.  The  slide  image  algorithm  performed  signif¬ 
icantly  better  (results  shown  in  Figure  32),  mainly  because  it  does  not  rely  on  an  initial  guess  transform. 
However,  when  the  ICP  algorithm  was  initialized  close  to  the  correct  solution,  it  out-performed  the  slide 
image  algorithm.  It  was  determined  that  the  slide  images  would  make  a  better  initialization  algorithm, 
whereas  ICP  would  be  used  as  the  primary  registration  algorithm.  In  addition  to  initializing  registration, 
the  slide  image  could  be  used  for  volumetric  analysis  of  the  tunnel  structure,  integrating  the  cross-sectional 
area  over  the  tunnel  axis.  One  of  the  problems  with  the  slide  image  representation  is  its  difficulty  in  han- 
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Figure  29.  Scan  segmentation  for  slide  image  generation. 


Figure  30.  Slide  image  histogram  generation:  (a)  tunnel  segment  with  point  and  gravity  vector,  (b) 
standard  2D  histogram. 
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Figure  31.  Gaussian  blurred  slide  image  histogram. 


dling  intersections  where  the  axis  is  ambiguous.  This  problem  could  be  solved  using  a  graph-based  axis 
instead  of  the  purely  linear  one.  These  algorithms  were  implemented  and  tested  using  lidar  scans  from 
border  tunnels  using  the  SSC  Pacific’s  Nodding  Hokuyo  lidar,  a  prototype  design  for  mechanically  rotating 
the  Hokuyo  UTM-30LX  horizontal  laser  scanner  along  its  y-lateral-axis  to  collect  a  full  3D  point  cloud. 
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Figure  32.  Accuracy  of  uninitialized  ICP  and  slide  image  pair-wise  registration;  data  capture  from 
Nodding  Hokuyo  lidar  in  border  tunnel. 
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6.5  STRUCTURE  FROM  MOTION 


Additional  localization  and  mapping  efforts  were  performed  using  structure  from  motion  (SfM),  a 
range  imaging  technique  that  estimates  3D  models  from  2D  images,  such  as  from  a  camera.  This  technol¬ 
ogy  finds  correspondences  between  images,  tracking  them  over  multiple  images,  which  then  reconstruct 
the  feature  3D  positions  and  the  motion  of  the  camera.  This  technique  provides  a  3D  model,  although  with 
a  scale  ambiguity.  The  SfM  capability  was  leveraged  from  the  SSC  Pacific  Urban  Environment  Modeling 
(UrbEM)  project,  which  uses  the  same  technology  found  in  Microsoft’s  PhotoSynth  [13].  UrbEM  was 
a  development  effort  focused  on  autonomously  building  rich  3D  models  of  urban  environments  from  a 
ground  perspective,  to  be  used  for  path  planning,  mission  planning,  and  training  for  warfighters,  along 
with  localization  for  moving  robotic  platforms.  A  sample  image  from  a  data  collection  in  the  cross-border 
Marconi  tunnel  is  shown  in  Figure  33,  with  an  image  of  the  3D  model  in  Figure  34. 


Figure  33.  Cross-border  Marconi  tunnel  steep  downward  steps. 
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Figure  34.  Cross-border  Marconi  tunnel  3D  reconstruction. 
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7.  AUTONOMY 


It  became  apparent  that  this  project  would  need  basic  autonomous  capabilities  such  as  traversing  the 
tunnel  while  avoiding  obstacles  and  creating  and  updating  a  map  for  the  user.  Not  only  would  wireless 
communications  be  intermittent  at  a  distance  of  400  meters  away  from  the  base  station,  but  it  tends  to 
be  hard  on  the  operator  to  teleoperate  a  vehicle  through  a  narrow  tunnel  for  such  a  long  period  of  time. 
SSC  Pacific  engineers  decided  to  use  Autonomous  Capability  Suite  (ACS),  an  advanced  autonomous 
behaviors  architecture  that  can  be  used  for  navigation,  mapping,  and  exploration  in  various  indoor  and 
outdoor  settings,  to  satisfy  the  needs  of  this  project. 


7,1  SOFTWARE:  AUTONOMOUS  CAPABILITY  SUITE  (ACS) 

SSC  Pacific  engineers  had  previous  experience  using  the  Autonomous  Capability  Suite  (ACS)  for 
autonomous  funcionality  integrated  on  the  PackBot®  with  other  SSC  Pacific  projects.  This  architecture  pro¬ 
vided  integration  of  navigation  sensor  drivers  and  perception  data  through  the  SSC  Pacific  CommonSense 
libraries,  and  navigated  autonomously  through  various  indoor  and  outdoor  environments  [14]. 

The  obstacle  avoidance  software  in  ACS  was  designed  for  a  single-scan  lidar,  so  software  modifica¬ 
tions  were  necessary  for  the  vehicle  to  function  with  NREC’s  3D  sensor.  The  limitations  of  computing 
power  on-board  the  CTER  robot  made  it  infeasible  for  the  obstacle  avoidance  algorithms  to  work  in  3D 
space  during  normal  operations  and  unnecessary  for  most  of  the  time  in  the  tunnels.  However,  the  3D  point 
clouds  made  it  possible  to  measure  the  height  of  objects  lying  in  the  path,  detect  overhangs,  or  classify 
slopes  and  determine  if  these  objects  were  indeed  obstacles  for  a  specific  robotic  platform.  An  algorithm 
was  developed  that  simplified  the  3D  stitched  point  cloud  into  a  two  and  a  half  dimensional  (2.5D)  obstacle 
grid  that  would  provide  height  information  about  approaching  objects,  overhangs,  and  slopes.  Each  spe¬ 
cific  robotic  platform  could  then  react  differently  to  objects  in  the  path  (e.g.,  the  CTER  could  climb  steps 
up  to  30  centimeters  in  height  whereas  the  PackBot®  would  avoid  objects  of  10  centimeters  or  greater). 
This  2.5D  grid  was  merged  into  the  ACS  2D  obstacle  map  to  provide  simple  path  planning  searches  and 
obstacle  avoidance. 

Path  planning  was  developed  to  explore  goal  points  in  areas  the  robot  had  not  mapped  before  and  plan 
appropriate  paths  to  those  locations.  However,  because  of  the  simple  linear  shape  of  most  drug-tunnels, 
autonomous  navigation  required  only  a  simple  open-space  behavior.  This  behavior  looks  for  space  in  front 
of  the  robot  that  is  open,  keeps  itself  centered  between  any  obstacles  on  its  left  and  right  side,  and  creates 
a  trajectory  that  moves  it  safely  through  that  space.  The  user-assisted  autonomous  software  mode  allowed 
the  user  to  provide  suggestions  of  rotation  (left  turn,  right  turn)  that  would  influence  the  behavior-based 
trajectory  planning  while  the  autonomous  navigation  would  continue  to  avoid  collisions. 
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8.  MULTI-ROBOT  OPERATOR  CONTROL  UNIT(MOCU) 


The  Counter  Tunnel  project  added  functionality  to  SSC  Pacific’s  existing  Multi-robot  Operator  Con¬ 
trol  Unit  (MOCU)  [15]  to  control  both  the  CTER  and  the  PackBot®  platforms  in  a  tunnel  exploration  mode 
by  creating  two  new  modules.  One  module  was  responsible  for  retrieving  and  displaying  the  obstacle  map, 
while  the  other  module  was  responsible  for  sending  control  messages  and  processing  the  video  feed  and 
vehicle’s  pose. 

MOCU  was  configured  to  connect  to  the  Autonomous  Capability  Suite  (ACS)  in  order  to  receive  the 
robot’s  pose  and  obstacle  map  data  as  well  as  to  provide  control.  MOCU  connected  directly  to  the  robot  to 
receive  the  video  feed.  A  display  configuration  was  set  up  to  allow  the  user  to  view  a  2D  map  on  the  bot¬ 
tom  left,  a  3D  terrain  map  on  the  right  and  a  live  video  feed  from  the  robot  in  the  upper  left  (as  shown  in 
Figure  35).  Robot  control  modes  are  selectable  via  an  on-screen  menu  that  is  navigated  via  a  gamepad  con¬ 
troller.  The  menu  allows  the  user  to  select  the  robot  for  control  and  switch  between  three  control  modes: 
Guarded  Teleop  (teleoperation  that  will  not  allow  the  user  to  hit  obstacles).  Teleop  (pure  teleoperation), 
and  Explore  (autonomous).  As  the  robot  is  driven,  MOCU  overlays  an  obstacle  map  over  the  2D  and  3D 
maps. 

MOCU  leveraged  a  previously  funded  SSC  Pacific  effort  with  the  Robotics  Technology  Consortium 
(RTC)  partner  Pelican  Mapping  which  placed  the  georeferenced  tunnel  point  cloud  (collected  from  the 
sensors)  in  the  map.  Point-to-point  measurement  on  the  rendered  scene  for  tunnel  characterization  model 
measurements  was  also  implemented. 


Figure  35.  Screenshot  of  MOCU  controlling  a  PackBol®  in  lab  space  with  an  obstacle  map  layered 
on  top  of  both  a  2D  map  and  a  3D  terrain  map. 
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9.  SYSTEM  TESTING  AND  DEMONSTRATION 


This  project  required  a  vastly  different  testing  environment  than  the  typical  indoor  or  outdoor  test  sites 
used  by  most  robotic  programs.  Finding  an  ideal  testing  location  in  itself  was  a  difficult  task,  especially 
one  that  could  provide  a  realistic  environment  in  keeping  with  project  objectives.  The  SSC  Pacific  project 
team  visited  various  sites  for  autonomous  robotic  exploration,  sensor  data  collection  and  analysis,  and  ra¬ 
dio  communication  tests.  The  ideal  test  sites  were  the  cross-border  tunnels  discovered  by  the  U.S.  Customs 
and  Border  Protection  near  the  U.S. -Mexico  border,  particularly  in  San  Diego.  However,  the  timeline  for 
testing  in  these  tunnels  was  always  short  because  the  Border  Patrol  fills  them  in  quickly  with  cement  for 
safety  and  security  reasons.  Because  of  the  lack  of  publicly  available  underground  tunnels  in  the  area,  at 
one  point  during  the  project,  SSC  Pacific  rented  and  tested  inside  a  commercial  mine  in  Julian,  California 
(it  is  humorous  to  note  the  reactions  from  the  SSC  Pacific  purchasing  department  when  they  reviewed  a 
request  to  rent  a  gold  mine  for  a  government- sponsored  activity).  Because  of  the  dangers  of  working  in 
enclosed  tunnel  environments,  SSC  Pacific  engineers  worked  closely  with  their  safety  office  for  training 
and  preparing  and  using  safety  gear  for  site  visits.  Figures  36a  through  36d  display  some  of  the  testing 
environments  that  were  visited. 


Figure  36.  (a)  A  tunnel  test  site  in  Twentynine  Palms,  (b)  PackBol®  maneuvering  in  a  cross-border 
tunnel,  (c)  CTER  maneuvering  through  a  test  tunnel  (d)  PackBol®  maneuvering  through  a  test 
tunnel. 
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9.1  JOINT  AFRL/SSC  PACIFIC  DEMONSTRATION 


A  joint  demonstration  was  held  with  AFRL  and  SSC  Pacific  in  June  2013.  The  details  of  this  event 
were  approved  with  a  Distribution  Statement  C,  distribution  authorized  only  to  U.S.  Government  agencies 
and  their  contractors.  To  be  able  to  receive  approval  for  public  release  (Distribution  A)  for  this  report,  the 
specifics  of  the  June  2013  event  have  been  left  out.  The  demonstration  included  sensor  data  collection, 
mapping  and  localization  within  a  tunnel,  autonomous  driving  through  various  ground  cover  and  wall 
texture  environments,  wireless  communications  with  repeater  nodes,  deployment  and  retrieval  of  the  CTER 
platform  through  the  Borehole  Deployment/Retrieval  Apparatus,  driving  the  CTER  robot  through  various 
modes,  as  well  as  climbing  up  and  scaling  down  30-centimeter  steps  and  crossing  over  30-centimeter  gaps. 


9.2  DEMONSTRATION  AND  TEST  WITH  U.S.  CUSTOMS  AND  BORDER  PROTECTION 

SSC  Pacific  held  an  additional  test  and  demonstration  event  near  the  border  of  California  and  Mexico 
with  the  U.S.  Customs  and  Border  Protection  in  November  of  2013,  demonstrating  control  of  a  CTER, 
AVATAR®  //,  and  a  PackBot®  platform  through  three  concrete  storm  drains.  Storm  drain  #1  was  a  45- 
centimeter-diameter  culvert  with  no  turns  and  a  length  of  about  10  meters.  Storm  drain  #2  was  a  1.5-meter 
diameter  culvert  with  one  90-degree  turn  at  20  meters  and  more  than  300  meters  long.  Storm  drain  #3  was 
a  1.5-meter  diameter  culvert  with  one  90-degree  turn  at  30  meters,  another  90-degree  turn  at  150  meters, 
and  a  total  length  of  350  meters.  Demonstration  participants  controlled  the  PackBot®  through  wireless 
communications  using  MOCU,  displaying  a  video  stream  and  overlaid  local  map  data  on  satellite  imagery. 
The  smooth  surface  and  relatively  straight  line  concrete  culverts  acted  as  an  RF  waveguide  for  the  wireless 
communications,  with  no  significant  multipath  or  occlusion  issues.  From  the  base  station  in  storm  drain 
#2,  802.1 1  wifi  provided  video  from  the  robot  to  the  user  allowed  control  of  the  robot  for  up  to  450  meters 
away. 

Tests  in  storm  drain  #3  provided  an  opportunity  to  use  repeater  communication  nodes  for  greater 
driving  distances.  As  was  expected  from  previous  communications  tests  in  other  tunnel  locations,  the 
wireless  signal  was  lost  after  the  second  90-degree  turn,  about  150  meters  from  the  base  station.  Manually 
Deployed  Communication  Relays  (MDCR),  a  variant  of  ihQ  Automatically  Deployed  Communication 
Relays  (ADCR)  [16],  a  proven  and  fielded  communications  product  developed  at  SSC  Pacific,  provided 
repeater  relay  communication  nodes  that  increased  the  wireless  communication  distance.  A  repeater  node 
placed  at  the  second  turn  provided  strong  communications  to  the  PackBot®  for  the  rest  of  the  tunnel  length, 
another  200  meters  (Figure  38a).  The  autonomy  system  was  able  to  successfully  travel  the  full  distance 
of  the  storm  drain  with  user  interactions  only  at  the  start  and  the  halfway  point  when  the  vehicle  turned 
around  (Figure  38b).  The  Border  Patrol  Program  Manager  mentioned  that  the  SSC  Pacific  autonomy 
running  the  PackBot®  through  the  storm  drains  was  “Border-Patrol-agent-proof,”  meaning  that  since  it  was 
hands-off  autonomy,  the  operators  could  not  break  it. 

The  AVATAR®  II  was  integrated  and  tested  for  wireless  teleoperation  and  mapping  with  the  MultiSense- 
SL.  The  AVATAR®  II  is  shown  with  the  Cobham  radio  for  wireless  communications  and  a  MultiSense-SL 
in  Figure  39.  This  platform  performed  with  similar  maneuverability  as  the  PackBot®  albeit  with  a  smaller 
obstacle  height  with  respect  to  the  mud,  rocks,  and  water  found  in  the  tunnels  due  to  its  low  profile  and 
smaller  fins. 

A  test  was  conducted  with  the  CTER  platform  through  storm  drain  #1,  shown  in  Figures  40a  through 
40c.  The  CTER  platform  was  connected  with  fiber  and  controlled  using  the  CTER  control  software  with 
video  and  position  feedback  as  shown  in  Figure  40b.  The  small  diameter  of  the  storm  drain  provided 
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(a)  (b) 


Figure  37.  (a)  Software  engineer  Jacoby  Larson  sends  the  PackBof’  into  a  storm  drain  near  the 
international  border  south  of  San  Diego  using  wireless  communications,  (b)  The  PackBof’  au¬ 
tonomously  traversing  and  mapping  the  1.5-meter  concrete  storm  drain. 


Figure  38.  (a)  Top-down  view  of  a  3D  point  cloud  of  storm  drain  #3  near  the  international  border 
south  of  San  Diego,  showing  two  90-degree  turns,  (b)  3D  point  cloud  of  the  end  of  the  storm  drain 
(the  red  box  represents  the  location  of  the  robot  in  the  scene). 
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Figure  39.  AVATAR®  II  robot  equipped  with  sensors  and  radios  about  to  enter  a  storm  drain  near 
the  international  border  south  of  San  Diego. 


a  very  unstable  surface  for  a  single-track  linear  platform  and  the  CTER  consequently  tipped  over  after 
traveling  only  3  meters.  The  small  width  of  the  culvert  made  maneuvering  and  recovering  from  tipover 
very  difficult,  especially  when  only  using  video  feedback.  The  test  team  attached  an  auxiliary  supporting 
structure  to  the  front  track  section,  as  seen  in  Figure  40c,  which  allowed  the  platform  to  successfully  drive 
the  remaining  length  of  the  concrete  pipe. 


Figure  40.  (a)  CTER  platform  about  to  enter  a  45-centimeter  storm  drain  near  the  international 
border  south  of  San  Diego,  (b)  The  video  feed  from  CTER  platform  as  it  traverses  the  storm  drain, 
(c)  The  attached  angled  fins  provides  stability  for  the  CTER  while  traversing  the  storm  drain. 
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The  SSC  Pacific  team  conducted  additional  mobility  tests  with  the  CTER  at  another  set  of  storm  drains 
with  varying  degrees  of  ground  cover:  soft  and  moist  dirt,  loose  sandy  steps,  and  large  rocky  terrain  (Fig¬ 
ures  41a  through  41c).  The  Border  Patrol  had  tested  other  platforms  at  these  test  sites  and  stated  that  none 
of  the  robots  could  climb  the  loose,  sandy  steps.  The  CTER  platform,  with  its  unique  control  and  maneu¬ 
vering  capabilities,  was  able  to  wriggle,  rotate,  and  climb  up  the  steps  in  its  predefined  Bend  mode. 


Figure  41 .  (a)  CTER  platform  beginning  to  traverse  sandy  terrain  in  a  storm  drain  at  the  interna¬ 
tional  border  south  of  San  Diego,  (b)  CTER  successfully  traversed  the  sandy  stepped  terrain,  (c) 
CTER  in  Bend  mode  traversing  rocky  terrain  in  another  storm  drain. 


The  Borehole  Deployment/Retrieval  Apparatus  was  not  tested  at  this  event,  but  feedback  from  the 
field  operators  was  that  it  did  not  require  much  more  effort  or  cost  to  dig  a  60-centimeter  borehole  than  a 
20-centimeter  borehole.  This  20-centimeter  borehole  requirement  was  the  main  driver  for  developing  a 
new  and  extremely  narrow  platform,  which  had  significant  negative  impact  on  cost,  schedule,  integration, 
and  testing. 


9.3  DATA  COLLECTION  OF  CROSS-BORDER  TUNNEL 

The  U.S.  Customs  and  Border  Protection  provided  support  for  a  data  collection  at  a  drug- smuggling 
tunnel  between  the  U.S.-Mexico  border,  discovered  in  November  2013,  linking  warehouses  in  San  Diego 
and  Tijuana.  U.S.  Customs  and  Border  Protection  normally  secures  such  a  tunnel,  drills  boreholes  from  the 
ground  surface  down  into  the  tunnel,  and  fills  it  with  concrete  so  that  it  cannot  be  reused.  SSC  Pacific  was 
asked  to  map  the  tunnel  and  provide  a  set  of  GPS  drilling  points. 

At  the  time  of  testing,  ventilation  in  the  tunnel  was  being  set  up  and  the  air  quality  was  unknown  past 
150  meters  into  the  tunnel,  which  meant  that  an  unmanned  platform  would  be  the  only  safe  way  to  map  the 
tunnel.  One  of  the  largest  risks  in  this  endeavor  was  that  if  the  unmanned  system  failed  to  respond  while  in 
the  tunnel  for  some  reason  (poor  communication,  broken  motors,  thrown  track,  etc.),  it  would  be  extremely 
difficult  to  retrieve. 

The  tunnel  was  equipped  with  a  rail  and  cart  system  (Figures  42a  and  42b)  that  made  driving  with 
the  PackBot®  only  possible  without  front  flippers  (the  flippers  were  too  wide  for  the  robot  to  fit  inside  the 
rails).  An  illustration  of  the  robot  configuration  is  shown  in  Figure  43.  The  tunnel  was  not  wide  enough  for 
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the  robot  to  turn  around,  so  retrieval  of  the  robot  required  that  it  be  driven  in  reverse.  The  initial  test  was 
conducted  with  the  robot  driving  150  meters  over  the  tracks  with  one  repeater  node  placed  at  75  meters  for 
communication.  Results  from  that  test  showed  that  the  hard  impacts  of  the  vehicle  lifting  up  and  falling 
down  over  the  cross  ties  caused  a  great  deal  of  noise  in  the  localization  measurements  and  created  a  useless 
map  of  the  tunnel. 


Figure  42.  (a)  Rail  and  cart  system  in  a  cross-border  tunnel  discovered  by  the  Border  Patrol,  (b) 
Supporting  cross  ties  for  the  rail  system  (the  rail  is  on  the  left). 


A  cart  was  conveniently  left  in  the  tunnel  and  another  test  was  conducted  with  the  robot  riding  on 
the  cart.  This  test  would  only  be  able  to  travel  as  far  as  a  human  operator  could  push  the  cart.  Because  of 
concerns  for  air  quality,  this  was  believed  to  be  about  150  meters.  However,  when  this  test  was  conducted, 
the  air  quality  sensors  reported  that  the  air  in  the  tunnel  was  within  acceptable  health  limits  far  beyond 
that  length.  The  robot  took  a  ride  on  the  cart  for  300  meters  to  the  end  of  the  tracks  where  the  tunnel  took 
a  90-degree  turn  to  the  left.  From  this  point,  the  air  quality  sensors  were  at  their  threshold  for  safety  and 
the  robot  was  sent  on  its  own.  The  base  station  was  set  up  at  this  turning  point  and  the  robot  was  driven  an 
additional  150  meters  over  another  set  of  tracks,  which  were  also  very  bumpy.  At  a  distance  of  150  meters, 
the  communication  was  poor  and  the  vehicle  was  driven  backwards  to  the  turning  point  and  the  test  was 
completed. 

The  map  created  from  the  MultiSense-SL  was  registered  correctly  up  to  the  turn  and  provided  a  good 
representation  of  the  tunnel,  shown  in  Figure  44.  No  wheel  odometry  sensors  were  used  during  this  test 
because  the  robot  rode  on  the  push-cart.  The  position  of  the  robot  in  the  tunnel  was  determined  using  only 
perception  system  sensors  and  the  visual  odometry  and  iterative  closest  point  algorithms.  To  be  able  to  pro¬ 
vide  accurate  georeferenced  drilling  points  for  this  tunnel,  the  point  cloud  had  to  be  merged  with  a  point 
cloud  that  had  an  accurate  representation  of  the  outside  world.  This  was  accomplished  using  a  number  of 
very  dense  point  clouds  collected  with  a  FARO  Focus3D  system,  stitched  together  using  spherical  fiducials, 
seen  in  Figure  45. 

The  overlap  of  the  two  point  clouds  was  not  significant  and  no  fiducial  markers  were  set  inside  the 
main  tunnel  body,  so  that  merging  of  these  point  clouds  together  was  accomplished  by  hand  using  open- 
source  3D  point  cloud  and  mesh  processing  software  called  CloudCompare.  This  hand  registration  intro¬ 
duced  alignment  error,  where  even  a  small  error  here  could  propagate  into  large  position  errors  further 
down  the  300-meter  tunnel. 
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Figure  43.  Pac/cSo/®  with  mounted  3D  sensor,  perception  computer  module  (black  box  behind 
sensor),  autonomy  module  (silver  box  on  right  rear),  and  radio  communications  module  (tan  box  on 
left  rear). 


Figure  44.  Point  cloud  of  tunnel,  captured  from  the  MultiSense-SL  sensor. 
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Figure  45.  Point  cloud  of  steps  leading  down  into  the  tunnel,  collected  by  the  FocusSD  sensor.  Two 
of  the  spherical  fiducials  used  to  stitch  scans  together  can  be  seen  on  the  left. 


This  merged  point  cloud  was  then  merged  with  a  georeferenced  top-down  aerial  lidar  collection  of  the 
San  Diego  area  from  the  USGS  2005  San  Diego  Urban  Region  Lidar  data  set.  Every  point  in  this  USGS 
aerial  point  cloud  has  a  NAD85  (HARN)  state  plane  zone  6  coordinate  which  can  be  converted  to  a  GPS 
coordinate.  Once  more,  this  aerial  point  cloud  data  set  was  merged  with  the  tunnel  data  set  by  hand,  which 
introduced  more  error,  but  provided  a  GPS  reference  to  the  tunnel.  An  illustration  of  the  overhead  view  of 
the  final  point  cloud  is  shown  in  Figure  46.  Estimated  GPS  points  were  extracted  from  the  tunnel  every  15 
meters  (Figure  47)  and  provided  to  the  U.S.  Customs  and  Border  Protection  agents  in  a  KML  file  for  easy 
access  in  Google  Earth™. 


Figure  46.  Point  cloud  of  tunnel  and  warehouse  merged  with  aerial  lidar  point  cloud. 


It  was  unclear  at  this  point  exactly  how  much  error  might  have  been  introduced  in  the  hand  merging 
of  point  clouds.  There  was  no  reference  point  provided  that  could  be  used  to  bias  the  information.  After 
drilling  was  completed,  a  KML  file  of  actual  drilling  points  was  created  to  compare  with  the  estimated 
drilling  points  of  the  tunnel.  An  image  of  the  estimated  and  actual  drilling  points  are  shown  in  Figures  48 
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Figure  47.  Overhead  view  of  point  cloud  of  tunnel  with  selection  of  drilling  points  every  15  meters. 


and  49.  The  direction  of  travel  of  the  merged  point  clouds  by  hand  turned  out  to  be  accurate.  However,  the 
largest  source  of  error  was  the  estimated  distance  of  the  tunnel.  The  actual  distance  of  the  tunnel  from  the 
warehouse  to  the  turning  point  was  336  meters  but  the  final  estimated  tunnel  length  in  the  point  cloud  was 
275  meters,  an  18%  error  in  distance. 

The  cause  of  the  error  in  the  distance  was  afterwards  determined  to  have  been  a  flaw  in  the  CloudCom- 
pare  software.  As  multiple  point  clouds  were  inserted  into  the  program,  they  had  to  be  merged  together 
by  rotating  and  translating  the  sets  so  they  fit  into  each  other.  It  was  discovered  that  the  multiple  rotations 
of  the  tunnel  point  cloud,  when  merged  with  the  warehouse  point  cloud,  caused  the  tunnel  to  decrease  in 
length.  The  tunnel  started  out  as  a  point  cloud  that  measured  308  meters,  but  after  multiple  rotations  in 
the  program,  was  measured  to  be  only  265  meters.  This  was  the  final  point  cloud  that  was  used  in  the  GPS 
drilling  point  estimations  and  this  change  in  distance  was  not  discovered  during  the  process.  A  test  was 
later  conducted  and  as  the  point  cloud  was  rotated  the  tunnel  distance  was  observed  to  decrease  in  size 
from  308  meters,  285  meters,  265  meters,  down  to  222  meters.  After  discussions  with  the  developers  of 
CloudCompare  about  the  issue,  it  was  discovered  that  the  computations  of  the  rotations  were  made  with 
standard  32  bits  (float)  precision  and  the  solution  was  for  them  to  use  double-precision  matrices  in  the  ren¬ 
dering  pipeline.  They  have  since  made  the  change  in  their  software  and  further  tests  reveal  that  the  length 
of  the  point  cloud  now  remains  the  same  after  multiple  rotations. 

This  test  showed  that  although  there  were  some  flaws  in  the  method  used  to  combine  3D  point  clouds 
and  provide  georeferenced  tunnel  points,  those  flaws  have  been  identified  and  there  is  an  immediate  and 
huge  potential  for  this  technology  to  be  used  for  newly  discovered  drug- smuggling  tunnels.  As  this  was  the 
first  time  the  SSC  Pacific  team  had  georeferenced  the  point  clouds  with  GPS  without  using  the  designed 
borehole  tunnel  and  fiducial  apparatus  system,  this  process  was  time-consuming  and  introduced  some 
errors.  This  method  could  be  refined  and  better  automated  with  additional  work  and  provide  a  more  ac¬ 
curate  and  safer  method  for  mapping  tunnels  and  providing  drilling  locations  where  air  quality  and  other 
conditions  make  it  dangerous  for  humans. 
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Figure  48.  Google  Earth™  image  with  overlayed  estimated  drilling  points. 


Figure  49.  Google  Earth™  image  with  overlayed  estimated  (yellow  dots)  and  real  drilling  points  (red 
squares). 
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10.  FUTURE  WORK 


The  Counter  Tunnel  project  has  explored  a  wide  range  of  technologies  and  advanced  the  resultant 
capabilities  needed  for  counter-tunnel  exploration  and  mapping.  Additional  work  is  required  to  transition 
these  technologies  to  the  agencies  that  will  put  them  to  use  in  day-to-day  activities  for  improving  security 
and  removing  humans  from  danger.  We  recommend  the  following  efforts. 

Primarily,  an  investigation  into  the  costs  associated  with  drilling  wider  boreholes  could  have  the  largest 
impact.  The  20-centimeter  borehole  requirement  drove  the  design  for  the  prototype  mobility  robot,  the 
smaller  perception  sensor,  and  the  specialized  Borehole  Deployment/Retrieval  Apparatus,  which  increased 
cost  and  risk.  This  cost  and  risk  might  be  prohibitive  to  the  government  agencies  working  in  tunnel  envi¬ 
ronments.  If  an  investigation  reports  that  a  larger  borehole  (such  as  60  centimeters)  is  not  cost  prohibitive 
(brief  discussions  with  Border  Patrol  agents  indicated  this  was  the  case),  it  could  create  a  pathway  for 
robotic  platforms,  larger  than  20-centimeter  width,  and  a  more  affordable  and  reliable  solution.  If  the  bore¬ 
hole  diameter  requirement  cannot  be  changed,  the  following  efforts  would  provide  the  greatest  return  on 
investment. 

It  is  recommended  to  further  miniaturize  the  perception  sensor  so  the  CTER  platform  will  not  tip-over 
from  the  sensor  weight.  Additional  effort  could  be  used  to  make  the  perception  solution  more  robust  to 
quick  rotations  or  a  lack  of  visible  texture  (such  as  when  the  sensor  is  within  centimeters  to  an  object,  like 
a  wall).  Future  work  should  integrate  other  sensor  data  (wheel  odometry,  gyroscope,  accelerometers,  or  an 
IMU)  with  the  data  from  the  MultiSense-SL  sensor  to  more  robustly  estimate  the  position  and  register  the 
point  clouds. 

There  is  a  need  to  perform  another  iteration  of  improvements  for  the  CTER.  Linkages,  reliability, 
and  insufficient  torque  should  be  addressed.  Further  modeling  and  algorithm  development  is  needed  to 
improve  the  Anti-Roll  mode  of  the  platform,  especially  when  it  is  carrying  heavy  payloads. 

The  Borehole  Deployment/Retrieval  Apparatus  was  designed  to  meet  the  tight  localization  require¬ 
ments  associated  with  deployment  down  the  borehole  shaft  30  meters  deep,  and  it  met  those  requirements 
using  a  high-end  IMU.  If  the  Borehole  Deployment/Retrieval  Apparatus  is  to  be  used  in  the  future  by  gov¬ 
ernment  agencies,  there  is  a  need  to  provide  accurate  localization  with  a  cost-effective  solution.  This  could 
involve  additional  sensors  and/or  an  improved  borehole  localization  algorithm. 

Further  research  in  the  use  of  quadrotors  or  some  small  UAV  platform  for  simple  exploration  and 
mapping  inside  tunnels  is  recommended.  Typically  these  quadrotors  have  a  battery  life  that  only  provides 
10-15  minutes  of  flying  time,  but  if  the  mapping  and  flying  maneuvers  are  fast  and  accurate,  10  minutes 
would  be  sufficient  to  fly  800  meters  through  a  tunnel  and  collect  data.  A  UAV  would  also  reduce  the 
amount  of  effort  that  would  be  needed  to  traverse  all  of  the  various  terrain  that  a  robot  encounters  inside 
tunnels:  dirt,  debris,  standing  water,  mud,  stairs,  steep  slopes,  etc. 

Continued  efforts  are  needed  for  UGV  tunnel  terrain  traversability.  Solving  problems  like  how  to  drive 
over  a  rail  and  cart  system  inside  a  tunnel  without  continuous  jarring  up  and  down  or  climbing  to  the  top  of 
steep  stairs  without  tip-over  could  be  an  avenue  for  research  that  would  provide  near-term  improvements. 

There  is  a  need  for  improved  methods  of  georeferencing  tunnels  to  GPS  coordinates.  The  data  collec¬ 
tion  through  the  border  tunnel  in  December  2013  demonstrated  that  it  is  currently  possible  to  determine 
this  positioning  with  a  surface  coordinate  system  (GPS),  but  not  without  significant  work.  Additional  effort 
is  needed  to  automate  the  point  cloud  registrations. 

Although  this  project  spent  time  testing  and  selecting  wireless  communication  radios,  the  chosen 
radios  were  not  tested  in  more  than  a  few  real-world  tunnel  environments.  It  is  therefore  strongly  recom- 
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mended  that  more  wireless  communication  tests  be  conducted  in  additional  tunnels  with  various  soil  types, 
sizes,  shapes,  and  curvatures. 
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11.  CONCLUSION 


The  Counter  Tunnel  project  has  focused  on  developing  UGV  solutions  to  explore,  localize,  traverse, 
characterize,  and  map  tunnel-like  environments.  Work  was  performed  jointly  by  AFRL  {CTER  snake 
platform  and  Borehole  Deployment/Retrieval  Apparatus)  and  SSC  Pacific  (sensor  processing,  tunnel 
characterization,  wireless  communications,  localization,  and  autonomy),  with  test  and  demonstration 
events  at  both  the  AFRL  Tyndall  Mock  Test  Tunnel  and  the  San  Diego  border  region. 

Despite  the  challenges  of  integration  on  a  new  prototype  UGV  platform  {CTER)  and  the  difficult  task 
of  localization  and  mapping  in  a  GPS-denied  tunnel  environment,  the  Counter  Tunnel  project  individually 
met  all  but  one  of  the  demanding  requirements  (the  CTER  was  not  tested  for  water  tightness  through  20- 
centimeter  standing  water).  The  project  successfully  demonstrated  deployment  into  and  retrieval  from 
a  tunnel  environment  through  a  20-centimeter-diameter  borehole,  climbing  30-centimeter  vertical  steps, 
crossing  30-centimeter  gaps,  transiting  over  800  meters  round  trip,  traversing  two  horizontal  45-degree 
turns,  operating  over  varied  and  rough  terrain,  autonomously  exploring,  localizing,  and  mapping  a  tunnel, 
generating  a  3D  model  of  the  tunnel,  and  locating  egress  points  within  1  meter  of  accuracy.  This  project 
has  advanced  the  state  of  the  art  in  the  areas  of  platforms,  sensors,  communications,  payloads,  GPS-denied 
navigation,  3D  perception,  and  mapping  in  the  realm  of  counter-tunnel  systems. 
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